How to Fix Docker 'Permission Denied' on docker.sock

You typed docker ps, and got: permission denied, while trying to connect to the docker API. Put sudo in front, which runs it as the administrator, root, and the same command lists the running containers: here, a music school's booking page. So Docker is fine. You just aren't allowed to talk to it. One popular fix lets every account on the PC talk to it, until the next reboot. We'll see which.

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

sudo docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'[sudo] password for ben:
bookings  nginx:alpine  Up 2 seconds

So who decides? The docker command is only a messenger. The work is done by the Docker daemon, a background service that runs as root. The two talk through one special file, docker dot sock. Think of that file as a staff-only door, with a keycard list: root, and the docker group. sudo runs the command as root, so it walks in. Ben, new in the school's office, is not on the list.

The list is printed on the file itself. ls dash l on slash var slash run slash docker dot sock shows it in ten characters. The s means socket. Then read and write for the owner, read and write for the group, and nothing for everyone else. The owner is root, the group is docker.

So the usual fix: put Ben on the list. First, id, which shows who you are, lists Ben's groups: ben and sudo. No docker. So Ben runs user mod with dash a capital G, docker, ben: capital G names a group, and dash a means add it to the ones he has. It prints nothing, which means it worked. Guess first: does his docker ps work now? No. The same error, word for word.

iduid=1001(ben) gid=1001(ben) groups=1001(ben),27(sudo)

sudo usermod -aG docker ben

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Why? Ask id about Ben by name, and docker is there. getent, which reads the group list, says so too: ana, ben. But plain id, about this terminal, still says no. Linux gives a program its groups when it starts, and Ben's shell started before the change. Back at the staff door: the list was updated, but Ben's keycard was printed when he logged in this morning.

id benuid=1001(ben) gid=1001(ben) groups=1001(ben),27(sudo),102(docker)

getent group dockerdocker:x:102:ana,ben

iduid=1001(ben) gid=1001(ben) groups=1001(ben),27(sudo)

So get a new keycard. new group docker starts a shell with the group, and docker ps works in it, but only in that one shell. The real fix is to log out and back in. Now plain id lists docker, and docker ps works without sudo.

newgrp docker

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'bookings  nginx:alpine  Up 1 second

exitexit

iduid=1001(ben) gid=1001(ben) groups=1001(ben),27(sudo),102(docker)

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'bookings  nginx:alpine  Up 3 seconds

Docker's own setup page agrees, and adds one detail: on a virtual machine, you may need to restart it before the group takes effect.

Read the error before you fix it, though. Earlier that day, Ana stopped Docker for an update, with systemctl, the tool that controls background services. Guess first: what does Ben's plain docker ps say then? Still permission denied. Linux checks the socket file's permissions before anything reaches Docker, so Ben never finds out nobody is home. Only with sudo does the real problem show: cannot connect. Is the docker daemon running?

sudo systemctl stop docker docker.socket[sudo] password for ana:

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

sudo docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

So match the message to the fix. Permission denied: the group. Older Docker versions, like 24, word it as the Docker daemon socket, with connect, permission denied at the end. Same cause. Is the docker daemon running: start it, with systemctl start docker.

Now the two fixes that backfire. The first is a missing letter. Ana adds a new helper, Eli, who is an admin: his groups include sudo. She types user mod dash capital G docker, but forgets the dash a. Without it, the list is replaced, not added to. Eli is in docker, and no longer an admin. Adding sudo back with dash a repairs it.

id eliuid=1003(eli) gid=1003(eli) groups=1003(eli),27(sudo)

sudo usermod -G docker eli

id eliuid=1003(eli) gid=1003(eli) groups=1003(eli),102(docker)

sudo usermod -aG sudo eli

id eliuid=1003(eli) gid=1003(eli) groups=1003(eli),27(sudo),102(docker)

The second is the popular one. C H mod changes a file's permissions, and six six six means read and write for owner, group, and everyone else. She runs it on the socket, and the last group of letters now says read and write for all. The staff door is propped open.

sudo chmod 666 /var/run/docker.sock

ls -l /var/run/docker.socksrw-rw-rw- 1 root docker 0 Nov 14 14:52 /var/run/docker.sock

Cara has a part-time account: no sudo, not in the docker group. Denied before. After the C H mod, she sees the booking page's container, while sudo still refuses her. Docker is open to every account on the PC.

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'bookings  nginx:alpine  Up 4 seconds

sudo ls /root[sudo] password for cara:
cara is not in the sudoers file.

And it doesn't even last. Ana reboots the PC. The socket is back to read and write for root and the group only, and Cara is denied again. systemd, the service manager that starts everything at boot, makes the socket fresh at every start, and its settings say: mode zero six six zero, group docker. So C H mod six six six is a hole that closes at the next reboot, and someone types it again.

sudo reboot

ls -l /var/run/docker.socksrw-rw---- 1 root docker 0 Nov 14 14:52 /var/run/docker.sock

systemctl cat docker.socket# /usr/lib/systemd/system/docker.socket
[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

So who belongs in the docker group? Docker's own page warns: the docker group grants root-level privileges. The daemon runs as root, and it starts whatever a group member asks for, with full control of the PC. So treat the docker group like sudo: add only people you'd trust as an admin.

So, permission denied on docker dot sock: join the group with user mod dash a G, then log out and back in. Cannot connect means Docker isn't running. Never C H mod six six six, which opens it to everyone, and add only people you'd trust with root.

If Docker answers you now without sudo, a like helps the next stuck beginner find this, and subscribing brings more fixes run on real machines.

Every error in this video came from a real Ubuntu PC with Docker, and every command and the lab files are linked in the description. Thanks for watching Cloud Explainers.

Sources

• Docker docs, Linux post-installation steps (the docker group, log out and back in, newgrp, the root-level privileges warning)
• Docker docs, Docker daemon attack surface
• Docker docs, rootless mode
• usermod(8): -G sets the list of groups; -a appends instead
• newgrp(1)
• credentials(7): a process's supplementary groups are set when it starts