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

The exact error string

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

Docker is a client–daemon system. The docker command talks to the background daemon (dockerd) over a Unix socket at /var/run/docker.sock. That socket is owned by root and the docker group, with group read/write permission — so to use it, you must be root or a member of the docker group. This error means the daemon is up and the socket is there; your user simply isn't allowed to open it. That's a crucial distinction from “Cannot connect to the Docker daemon”, which means the daemon isn't running at all.

Before you assume it's a permissions issue, rule out the daemon itself — a stopped or crashed daemon can sometimes surface as a permission-flavored message too, depending on the client version:

sudo systemctl status docker

If that shows the daemon as inactive or failed, you're actually looking at a different error — start the daemon first, and this page no longer applies. If it shows active (running), the daemon is fine and the rest of this page is the right fix.

Confirm what you're looking at

# the socket exists and shows group "docker" with rw permission:
$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Jul 14 09:00 /var/run/docker.sock

# your user's groups — note whether "docker" is present:
$ id
uid=1000(dev) gid=1000(dev) groups=1000(dev),27(sudo)   # ← no "docker"

# simpler, and what most tutorials show:
$ groups
dev sudo

Reading the ls -l output left to right: srw-rw---- breaks down as a socket file (s) with owner permissions rw-, group permissions rw-, and others --- — meaning owner = root (full access), group = docker (full access), and everyone else = no access at all. The socket's group is docker, but the user above isn't in it — exactly the mismatch that produces the error. groups is the shorter command for the same check; id additionally shows your UID/GID numerically, which is useful when debugging inside containers.

The permanent fix: add your user to the docker group

sudo usermod -aG docker $USER

The -aG matters: -a means append, and without it usermod -G would replace all your other group memberships (including sudo) — a classic footgun. This one command is the entire fix; the rest is just making it take effect.

Apply the new group membership (the step people miss)

Group changes only apply to new login sessions. Your current shell started before the change, so it still doesn't see docker in your groups — which is why the error often persists right after running usermod. Pick one:

# option A: start a subshell with the updated groups (no logout needed)
newgrp docker

# option B: log out completely and back in (or reboot)

# then confirm — "docker" should now be listed:
id
docker ps    # ✅ works without sudo

Over SSH, closing and reopening the connection is enough; on a desktop, a full log out–in (not just a new terminal tab) is the reliable option.

If usermod complains that the group doesn't exist, create it first with sudo groupadd docker, then re-run the usermod command — a fresh install or a package that didn't create the group on setup can leave it missing. You can confirm the group exists at any time with getent group docker, which prints the group and its members.

Why not just use sudo?

sudo docker ps works, and it's fine for a one-off. But as a permanent approach it has two real downsides: you must prefix every command with sudo, and files a container writes to a bind-mounted host directory can end up owned by root, creating permission headaches later. Adding your user to the docker group removes both problems.

The stricter alternative: rootless Docker

Rootless mode runs the daemon as your own unprivileged user, so there's no root-owned socket and no docker group to join — the whole permission question disappears, at the cost of a few feature limitations. It's the right choice on multi-user machines:

dockerd-rootless-setuptool.sh install
# then use the per-user socket it configures, e.g.:
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

Note for macOS and Windows

This error is essentially Linux-only. On Docker Desktop (Mac/Windows) the daemon runs inside a managed VM and the client connects through a per-user socket or named pipe, so there's no host docker group to configure. If you hit a connection problem there, it's almost always the daemon not being started — see Cannot connect to the Docker daemon.

Debugging checklist

• ✓ sudo systemctl status docker — rule out the daemon not running first
• ✓ ls -l /var/run/docker.sock — confirms the socket exists, group docker
• ✓ id or groups — is docker in your group list? If not, that's the cause
• ✓ sudo usermod -aG docker $USER — note the -a (append, don't replace)
• ✓ newgrp docker or log out/in — group changes need a fresh session
• ✓ docker ps now works without sudo
• ✓ Shared/production host? Prefer rootless Docker over the group (it's root-equivalent)