docker permission denied socket /var/run/docker.sock — how to fix

When this happens

Got permission denied while trying to connect to the Docker daemon socket at
unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create":
dial unix /var/run/docker.sock: connect: permission denied

Your user does not have permission to access the Docker socket. Adding yourself to the docker group grants access without sudo. This is the usual "docker permission denied socket" error.

What is being denied

The Docker client cannot open the daemon control socket

On a typical Linux installation, the Docker CLI sends API requests to the daemon through /var/run/docker.sock. The socket is usually owned by root:docker and permits members of the docker group to connect. This error occurs before Docker evaluates an image or container command.

Membership in the docker group is effectively root-level access: a user who can control the daemon can mount the host filesystem or start privileged containers. Add only trusted accounts, and prefer rootless Docker on shared or security-sensitive machines.

Diagnose first

Check the daemon, socket ownership, and current group session

A missing or inactive daemon can produce a similar connection failure, so confirm the service before changing permissions. The id output reflects groups active in the current login session; editing /etc/group does not update an already-running shell automatically.

If the service is inactive, start or troubleshoot the daemon instead of changing the socket mode.
If your username appears in getent group docker but not in id, start a new login session or use newgrp docker.
If the active Docker context is not the local default, inspect its endpoint with docker context inspect.

systemctl is-active docker
ls -l /var/run/docker.sock
id
getent group docker
docker context show

Apply the group change

Refresh the login session, then test a disposable container

After usermod, logging out and back in is the most predictable way to refresh all desktop and terminal processes. newgrp docker starts a subshell with the new primary group and is useful for an immediate terminal test, but other open applications keep their old group list.

sudo usermod -aG docker "$USER"
newgrp docker
id
docker run --rm hello-world

Unsafe workaround

Do not chmod the Docker socket to 666

Making /var/run/docker.sock writable by every local user exposes full daemon control and is usually reverted when Docker restarts. It treats the symptom while removing the access boundary. Restore normal ownership through the service configuration, then use the group or rootless mode deliberately.

# Avoid this insecure workaround
# sudo chmod 666 /var/run/docker.sock

# Typical socket ownership
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock

Environment differences

Docker Desktop and rootless Docker use different endpoints

Docker Desktop on macOS and Windows does not use Linux host group membership in the same way. Confirm that Docker Desktop is running and that the selected context points to its managed socket. Rootless Docker uses a user-owned socket under $XDG_RUNTIME_DIR; set or select the endpoint created by the rootless setup rather than modifying /var/run/docker.sock.

Other approaches

Run with sudo (quick but not recommended)

Using sudo can confirm that the daemon is reachable, but it may create root-owned files in bind mounts and in ~/.docker. Treat it as a diagnostic step rather than the permanent fix.

sudo docker run --rm hello-world

Check the docker group exists

grep docker /etc/group
# If missing, create it:
sudo groupadd docker

Rootless Docker — run Docker without root

Rootless mode runs the Docker daemon as a non-root user, improving security.

# Install rootless Docker (Ubuntu/Debian)
dockerd-rootless-setuptool.sh install

# Add to your shell profile
export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock