Docker: "permission denied ... docker.sock" — how to fix it

You typed docker ps and got permission denied while trying to connect to the docker API at unix:///var/run/docker.sock. Docker is installed and running. Your user just isn't allowed to talk to it. The fix takes one command and one re-login, and below we explain why it works and what it costs you in security.

TL;DR. The Docker daemon listens on a socket file that only root and the docker group can open. Add yourself to that group with sudo usermod -aG docker deploy (replace deploy with your username), then log out and log back in. Already-open sessions do not pick up the new group. Do not run chmod 666 on the socket. Membership in the docker group is effectively root access, so only add people you trust.

We reproduced all of this on a fresh test server: Ubuntu 24.04, Docker 29.1.3 from the docker.io package in apt, a regular user deploy without sudo rights. The commands and outputs in the main steps come from that run. We did not test chmod 666, so that one is advice only.

What the error actually says

This is the exact message on a current Docker:

The docker command you type is only a client. The real work is done by the Docker daemon, a background service that runs as root. The client reaches it through a socket: a special file, /var/run/docker.sock, that programs use to talk to each other on the same machine. The message means the client found the file and was refused when it tried to open it. Older Docker versions word the message differently and at greater length, but the cause is the same.

Note what this is not: it is not a network problem and not a broken install. The daemon is up and answering; it simply won't let you in.

Why your user is refused

Look at who owns the socket. This command lists the file with its permissions:

ls -l /var/run/docker.sock

You should see:

srw-rw---- 1 root docker ... /var/run/docker.sock

• s at the start: this is a socket, not a regular file.
• rw-rw----: the owner (root) and the group (docker) can read and write; everyone else gets nothing. In octal that is 0660.
• root docker: owner and group. Only these two may use the socket.

This is set on purpose: the unit file /lib/systemd/system/docker.socket contains SocketMode=0660 and SocketGroup=docker. Now check who is in the group:

getent group docker

On the test server it printed docker:x:112:. Nothing after the last colon means the group is empty. The number 112 (the group ID) can be different on your machine. Your user is not root and not in the group, so the kernel says no.

The fix: add your user to the docker group

You need one thing first: access to an account that can use sudo (or the root account), because changing group membership is an admin action. Then run:

sudo usermod -aG docker deploy

• usermod edits a user account.
• -G docker sets the supplementary group; -a means "append". Never drop the -a: without it usermod replaces all the user's groups with just docker, and you can lose sudo access.
• deploy is the account being changed. Not sure of yours? Run whoami.

The command prints nothing on success. Confirm with id deploy: the list should now end with 112(docker) (or your own group number).

The trap: your open session still does not see the group

This is where most people think the fix failed. Linux reads a user's groups once, at login. A terminal or SSH session opened before usermod keeps the old list. We checked it: with a deploy session open before the change, id -nG still showed deploy users and docker ps was still denied.

The clean solution is to log out and back in. For an SSH session, type exit and connect again. A new login sees the group and docker ps works.

If you cannot reconnect right now, there are two workarounds. Both worked in our test:

sg docker -c "docker ps"

sg runs one command with the docker group switched on, then returns you to normal. Good for a one-off check.

newgrp docker

newgrp starts a subshell where the group is active. Run your Docker commands there; type exit to leave. It does not change your original session, so a fresh login is still the proper fix.

Check that it works

After the new login, confirm that the group is active and that Docker answers:

id -nG

docker ps

The first command should list docker among your groups. The second prints a table header (CONTAINER ID IMAGE ...), followed by your containers or nothing at all if none are running. An empty table is success. The error is gone.

Security: the docker group is root

This part matters. Whoever can talk to the Docker daemon can ask it to start a container with any folder of the host mounted inside. The daemon is root, so the container is too. We ran this as the unprivileged deploy user:

docker run --rm -v /:/host alpine:3 chroot /host id -un

• -v /:/host mounts the whole server disk into the container at /host.
• chroot /host makes that folder the container's root, so it behaves like the real system.
• id -un prints the current user name.

It printed root. A user with no sudo rights just became root on the host. So treat the docker group like the sudo group: add your own deploy account and people you would trust with the root password. Do not add a shared "app" user, a web-facing service account, or a contractor you met last week.

What not to do

chmod 666 /var/run/docker.sock. It looks like a shortcut: everyone can now open the socket. That also removes the only protection, so any account on the server, including a compromised website process, gets root through Docker. As a rule the change also disappears when docker.socket restarts, so you get a hole and a fix that breaks later. We did not apply it in the lab; this is advice, not a test result.

Typing sudo before every command, forever. It works if your account has sudo rights. A user without them gets a failed password prompt in a terminal, and sudo: a password is required in a script (we saw the second on deploy). Even where it works, it does not fix scripts, cron jobs or Compose files run by that user, and files that containers write into mounted folders can end up owned by root. Use sudo for a quick look, and put the user in the group for daily work.

Logging in as root just to run Docker. It sidesteps the error, and also the habit of working under a limited account. Keep root for administration.

FAQ

Why does docker still say permission denied after I added myself to the group?

Your current session was started before the change, and Linux reads groups at login. Log out and back in, or use sg docker -c "docker ps" for a one-off check. In our test an open session kept denying access until we reconnected.

Is it safe to add a user to the docker group?

Only for users you would trust with root. Group members can start a container with the host disk mounted and become root on the server, which we demonstrated with a single docker run command. If that is not acceptable, give the user no Docker access at all and run the containers yourself.

Can I fix this with chmod on docker.sock?

You can, but you should not. chmod 666 lets every account on the machine control Docker, which means root. It is also likely to be reset when the socket restarts. Use group membership instead.

Do I need to restart Docker after usermod?

No. The daemon keeps running as is. Only the user's session needs to be refreshed, because the new group shows up at the next login.

Does this apply to snap, rootless Docker or Docker in CI?

We have not tested those, so we will not guess. This article covers the docker.io package from Ubuntu's apt repository on Ubuntu 24.04. A rootless setup uses a different socket and a different permission model.

Takeaways

• The error means the socket /var/run/docker.sock (root:docker, mode 0660) refused your user, who is not in the docker group.
• The fix: sudo usermod -aG docker deploy, then log out and back in. Keep the -a.
• A session opened before the change does not see the group. Use a fresh login; sg and newgrp are temporary workarounds.
• The docker group equals root on the host. Add only trusted accounts.
• Never chmod 666 the socket, and do not rely on endless sudo for scripts.

What's next

With Docker working for your user, you can run several services together in Docker Compose on one VPS. And when images and logs start eating the disk, see how to find what takes the space and clean it safely.