Fix Docker "permission denied /var/run/docker.sock" in 5 Minutes

Fix Docker "permission denied /var/run/docker.sock" in 5 Minutes

Seen that red error message again?

You've SSH'd into a server, typed a casual docker ps, and gotten this:

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

So you fall back to sudo docker ps as a temporary workaround, then it fails again on the CI runner... This post is how you break that loop. We'll go error message → root-cause diagnosis → copy-paste commands and get you to a permanent fix in five minutes.

Why it fails — how docker.sock permissions work

Let's look at the culprit first.

ls -l /var/run/docker.sock
# srw-rw---- 1 root docker 0 Jun 24 09:12 /var/run/docker.sock

Breaking down that output explains everything.

• s: not a regular file — a Unix socket
• rw- (owner root) / rw- (group docker) / --- (others): only root or members of the docker group can read and write
• Ownership: root:docker

Docker's daemon (dockerd) runs as root, and the docker CLI is just a client that writes commands to this socket.

[docker CLI] --(socket write)--> /var/run/docker.sock --> [dockerd (root)]
 : root:docker
 : srw-rw----

So if your account is not a member of the docker group, you can't write to the socket and you get permission denied. The takeaway is simple: docker group membership is the key.

5-minute diagnosis table by cause

Match your symptoms to a case first.

Copy-paste fix commands

Case ① Add yourself to the group

# check
id

# docker
sudo usermod -aG docker $USER

# when
newgrp docker

# check - docker
groups

The cleanest approach is exit then reconnect SSH. A new shell starts with the updated group info.

Case ③ When the socket is corrupted

ls -l /var/run/docker.sock # check
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock
sudo systemctl restart docker # when socket

Case ④ Rootless Docker

# rootless User dedicated socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
docker context use rootless

"I ran usermod and it still doesn't work" — the most common trap

This is where people get stuck the most. If you've already run usermod -aG docker and still get permission denied, the first thing to suspect is that your current shell session still has the old group info.

Group membership is baked into the shell at login, so an already-running shell does not update automatically. Compare these two:

id # " " → docker
groups #

getent group docker # when DB → !

If it shows up in getent but not in id, the session hasn't been refreshed. Fix it with one of these three:

1. newgrp docker — enter a subshell with the new group (immediate)
2. Fully log out and reconnect SSH — most reliable
3. sudo systemctl restart docker then reconnect (also covers socket issues)

Practitioner tip: If you're working inside a tmux/screen session, newgrp alone may not be enough. Kill the session completely and reattach. I once burned 30 minutes because I didn't know this.

When the daemon is down or the docker group is missing, and WSL2

Sometimes what looks like a permission problem is a daemon that isn't running. In that case the message is different—Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?—so tell the two apart first.

systemctl status docker        # check that it is active (running)
sudo systemctl start docker    # start it if it is stopped
sudo systemctl enable docker   # start automatically at boot
getent group docker            # check that the docker group exists
sudo groupadd docker           # only if the group is missing ("already exists" is safe to ignore)

On WSL2, where to fix it depends on your setup. Docker docs: Linux post-installation steps

On WSL2 the same instance keeps running even when you open a new shell, so group changes may not take effect. wsl --shutdown does the job of a re-login.

Temporary workaround vs permanent fix vs rootless

Environment-specific notes (CI/CD)

• GitHub Actions: Official Ubuntu runners already have permissions set, so it just works. For self-hosted runners, add the runner user with sudo usermod -aG docker <runner-user> and restart the runner service.
• GitLab Runner: If you mount the host socket (-v /var/run/docker.sock:...) instead of DinD (docker:dind), the GID of the user inside the container must match the host docker group's GID.
• Trend: Because of DinD's security and performance cost, BuildKit / socket-mount approaches are becoming more common in CI. Docker Desktop licensing issues have also driven adoption of Podman and colima.

Wrap-up: permanent-fix checklist + security warning

□ id docker
□ ls -l /var/run/docker.sock srw-rw---- root docker
□ usermod after (or newgrp)
□ sudo without docker ps

One last point, stated bluntly: a docker group member can mount the host root filesystem (-v /:/host) and effectively seize root. In other words, docker group = root.

So avoid casually adding people to the group on shared or production servers. Prefer rootless Docker or sudo plus audit logging. On a personal dev box, adding the group is the most convenient option — just know what it means.

One-liner: If you're blocked, check the group with id → if missing, usermod -aG docker $USER → re-login → docker ps. Bookmark this so you don't get lost next time.

References: official docs

The primary source for the behavior, settings, and errors in this post is the official documentation below. Check it for version-specific options and exact behavior.

• Docker official documentation

FAQ

Q. I ran usermod and still get permission denied. A. Your current shell still has the old group info. If you're in getent group docker but not in id, the session hasn't been refreshed. Fix it with newgrp docker or a full SSH reconnect.

Q. Is it safe to use Docker without sudo? A. The docker group is effectively equivalent to root. Fine on a personal server; on shared or production servers, prefer rootless Docker or a sudo audit policy.

Q. Do the same commands work on WSL/Mac? A. No. Docker Desktop uses a separate backend, so this is often unrelated to group membership. Check Desktop settings and whether WSL integration is enabled first.