Docker "permission denied … docker.sock": the fix

Fix Docker "permission denied" on /var/run/docker.sock: add your user to the docker group, make it take effect, and know why chmod 666 is a bad idea.

You run a Docker command without sudo and get:

$ docker ps
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Docker versions before 29 say more, with the request they were making:

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

The meaning is the same. The docker command is only a client: it talks to the Docker daemon through the socket file /var/run/docker.sock. That file belongs to root and to the group docker, and your user is neither. With sudo it works, because root may open it.

Your usernot root, not in the docker group
permission denied(fails)
/var/run/docker.sockowned by root, group docker(breaks here)
leads to
dockerdrunning, never reached

docker talks to the daemon through a socket file owned by root and the docker group. Your user is neither, so opening it is refused; with sudo it works.

TL;DR

sudo usermod -aG docker $USER    # add yourself to the docker group
# log out and back in (or reconnect over SSH), then:
docker ps                        # works without sudo

1. Check the socket and your groups

ls -l /var/run/docker.sock
id

srw-rw---- 1 root docker 0 Nov  1 09:02 /var/run/docker.sock
uid=1000(guest) gid=1000(guest) groups=1000(guest),27(sudo)

The socket is readable and writable by root and the docker group (rw-rw----), and docker is missing from your groups. That’s the whole problem.

2. Add your user to the docker group

sudo usermod -aG docker $USER

-aG means “append to this Group”. Without -a, usermod -G replaces all your other groups — and you could lose sudo.

If you get usermod: group 'docker' does not exist, the package didn’t create it (it happens with some installs). Create it, and restart Docker so the socket gets the group:

sudo groupadd docker
sudo usermod -aG docker $USER
sudo systemctl restart docker

3. Make it take effect

This is where most people get stuck: you’re in the group, and it still says permission denied. Linux reads your groups when you log in. A shell that was already open keeps the old list — id still doesn’t show docker.

Log out and back in. Over SSH, disconnect and connect again.
Or, for the current shell only: newgrp docker.
VS Code Remote / tmux / screen keep a session running in the background, so a reconnect isn’t enough: restart the remote server, or the tmux / screen session.
Services that run Docker commands (Jenkins, a CI runner) also read their groups only when they start: sudo usermod -aG docker jenkins, then sudo systemctl restart jenkins.

Check with id — docker should be in the list — then run docker ps again.

Warning

The docker group is as powerful as root. Anyone in it can run docker run -v /:/host … and read or change every file on the machine. Add only people who could have sudo anyway. For a hardened setup, look at rootless Docker, which runs the daemon as your user.

Don’t “fix” it with chmod

Many answers online suggest:

sudo chmod 666 /var/run/docker.sock    # don't

It “works” because now every user and every process on the machine can control Docker — which, as above, means they can become root. It also doesn’t last: Docker re-creates the socket with the normal permissions when it restarts. Use the group.

The daemon isn’t running

A different message means a different problem:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Here the socket isn’t there at all, because Docker isn’t running. Start it, and make it start at boot:

sudo systemctl enable --now docker
systemctl status docker --no-pager

If it fails to start, the reason is in sudo journalctl -xeu docker — see Job for … failed because the control process exited with error code.

Shell, we have a problem!

Similar, but different: with Docker Desktop on Linux, the CLI talks to Desktop’s own virtual machine through another socket. docker context ls shows which one is active (desktop-linux or default), and docker context use default switches back to the system Docker Engine. In rootless Docker, the socket is in your home runtime folder, so DOCKER_HOST must point to unix://$XDG_RUNTIME_DIR/docker.sock. If the daemon isn’t running at all, see Cannot connect to the Docker daemon. For the commands around this, see the Docker CLI Cheat Sheet.

Docker: "permission denied while trying to connect to the Docker daemon socket"

TL;DR

1. Check the socket and your groups

2. Add your user to the docker group

3. Make it take effect

Don’t “fix” it with chmod

The daemon isn’t running

Try it yourself

Linux Terminal Playground

Docker Compose Generator

Related articles

Docker "pull access denied": the repository doesn't exist, or you're not logged in

Alpine "not found" for a binary that's right there: glibc vs musl

Docker "exec format error": the wrong CPU architecture, or a script with no shebang

Related articles

pull access denied
Docker & Containers
Docker "pull access denied": the repository doesn't exist, or you're not logged in
Fix Docker "pull access denied, repository does not exist or may require docker login": check the image name and tag, log in to the right registry, handle rate limits.
Beginner · 4 min read

not found
Docker & Containers
Alpine "not found" for a binary that's right there: glibc vs musl
A binary exists on Alpine, yet running it says "not found" or "no such file or directory": it was built for glibc. Check with ldd, then rebuild it or use gcompat.
Intermediate · 4 min read

exec format error
Docker & Containers
Docker "exec format error": the wrong CPU architecture, or a script with no shebang
Fix Docker "exec /app: exec format error": an image built for another architecture (arm64 vs amd64) or a script with no shebang. Check it, then build with buildx.
Intermediate · 4 min read