Fix: Permission Denied on the Docker Daemon Socket

You ran a normal docker command on Linux and got this instead of output:

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

On older Docker versions the same problem reads a little differently, but it is the exact same wall:

1Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Nothing is broken. Docker is running fine. Your user account just is not allowed to talk to it yet. This guide shows you why that happens, the one-line fix that gets you working right now, the permanent fix, and the one "fix" you should never copy from a random forum answer.

Why this happens

Docker does its real work in a background service (the daemon) that runs as root. Your docker command is just a client. It talks to the daemon through a Unix socket, a special file at /var/run/docker.sock. Look at who owns that file:

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

1srw-rw---- 1 root docker 0 Sep 10 15:41 /var/run/docker.sock

Read that line right to left. The socket is owned by user root and group docker, and its permissions are rw for the owner, rw for the group, and nothing for everyone else. So only root and members of the docker group can read from or write to it. A brand-new user is in neither:

1id

1uid=1000(tester) gid=1000(tester) groups=1000(tester)

No docker group in that list, so the connection is refused. That is the whole story. The error is a file-permission error wearing a scary costume.

Fix 1: run it right now with sudo

If you just need the command to work this second, run it as root with sudo:

1sudo docker ps

1NAMES     STATUS

The command connects and returns cleanly (an empty table here just means no containers are running). This is fine for a one-off, but typing sudo before every docker command gets old fast, and it means every container you start is being managed as root. For your own machine, set up the permanent fix instead.

Fix 2: add your user to the docker group (the real fix)

Add your user to the docker group once, and you never need sudo for Docker again:

1sudo usermod -aG docker $USER

-aG means "append to this group" (the -a matters; without it you would replace all your other groups). Confirm it took:

1id

1uid=1000(tester) gid=1000(tester) groups=1000(tester),990(docker)

There is the docker group. But if you try docker ps in the same terminal, you may still get permission denied, and this is the step everyone trips on.

Get a fresh session in any one of these ways:

1# option A: load the new group into the current shell right now2newgrp docker3 4# option B: log out and back in (or close and reopen your terminal)5 6# option C: over SSH, disconnect and reconnect

After that, Docker works as your normal user, no sudo:

1docker ps

1NAMES     STATUS

Connected, no permission error, no sudo. That is the fix you want.

The "fix" to avoid

Search this error and you will find answers telling you to just open up the socket:

1# do NOT do this2sudo chmod 666 /var/run/docker.sock

It makes the error go away, and it is a genuinely bad idea. 666 lets every user and process on the machine read and write the Docker socket. Anyone who can talk to the Docker daemon can start a container that mounts your entire host filesystem as root, which is effectively handing them root on the box. The docker group already gives your user that same power, so understand what you are joining.

Quick reference

1# see who owns the socket (root:docker, group-only access)2ls -l /var/run/docker.sock3 4# right now, one-off5sudo docker ps6 7# permanent: join the group, then start a fresh session8sudo usermod -aG docker $USER9newgrp docker      # or log out and back in10docker ps          # works, no sudo

That is every legitimate way out of this error. If sudo docker ps also fails, your problem is different: the daemon itself is not running. Start it with sudo systemctl start docker and check sudo systemctl status docker.

New to Docker and want the mental model behind all this? Start with our guide on running your first containers, then work through the Docker Foundations series.