🚨 Docker Error Guide: 'permission denied while trying to connect to the Docker daemon socket' Access Errors

Exact Error Message

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

Common variants depending on the command and Docker version:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/images/create?fromImage=nginx&tag=latest": dial unix /var/run/docker.sock: connect: permission denied

dial unix /var/run/docker.sock: connect: permission denied

What It Means

This error is the close cousin of “Cannot connect to the Docker daemon,” but the distinction matters: here the daemon is running and the socket does exist — your user simply is not allowed to open it. The Docker daemon socket /var/run/docker.sock is owned by root and the docker group with mode 660 (read/write for owner and group, nothing for others). If your user is neither root nor in the docker group, the kernel refuses the connect() and you get permission denied.

Because the daemon answered with a filesystem-level rejection rather than a missing endpoint, this is an authorization problem, not a connectivity problem. The single most useful test to confirm this is to repeat the failing command with sudo: if sudo docker ps succeeds while docker ps fails, the daemon is healthy and the problem is entirely about who you are, not whether the daemon is up. That one comparison short-circuits most of the guesswork.

It is worth understanding why Docker is wired this way. The daemon runs as root because creating containers requires privileged operations — namespaces, cgroups, mounts. Rather than expose that power to every local user, Docker restricts the control socket to root and a dedicated docker group. The permission-denied error is that restriction doing its job; the fix is to legitimately grant access, not to weaken the restriction.

Common Causes

• User is not in the docker group. The most common cause: the socket is root:docker 660 and your account is in neither.
• Group added but session not refreshed. You ran usermod -aG docker $USER, but your current shell still has the old group set — you need newgrp or a fresh login.
• Socket has unexpected ownership or mode. A reinstall or custom unit left the socket root:root or 0600, so even docker group members can’t reach it.
• SELinux / AppArmor denial. A mandatory access control policy blocks the socket even though POSIX permissions look correct.
• Rootless vs rootful mismatch. You are reaching for /var/run/docker.sock (rootful) while only a rootless daemon is running on /run/user/<uid>/docker.sock, or vice versa.

How to Reproduce the Error

Reliable to reproduce. From a user that is not root and not in the docker group, run any command that hits the API:

# As a non-privileged user with no docker group membership
id            # confirm: no "docker" group listed
docker ps
# Got permission denied while trying to connect to the Docker daemon socket ...

The daemon is healthy throughout — sudo docker ps works fine, which is the tell-tale sign this is a permission problem and not a dead daemon.

Diagnostic Commands

Confirm your group membership, then confirm what the socket actually requires.

# Which groups am I in right now? Is "docker" among them?
id
groups

# What does the socket require? Expect: srw-rw---- root docker
ls -l /var/run/docker.sock

# Proof the daemon is up and it's purely a permission issue
sudo docker info | head -5

# SELinux denials (if enforcing)
sudo ausearch -m avc -ts recent 2>/dev/null | grep docker.sock

A correctly owned socket looks like:

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

If id shows no docker group but sudo docker ps works, the diagnosis is settled — you need group membership (or rootless Docker).

Step-by-Step Resolution

1. Add your user to the docker group.

   sudo usermod -aG docker "$USER"

2. Refresh your group membership. The change does not apply to your current shell. Either log out and back in, or start a subshell with the new group:

   newgrp docker
   # verify
   id | grep -o docker
   docker ps

3. If the socket ownership is wrong, restore it by restarting the daemon (which recreates the socket via docker.socket):

   sudo systemctl restart docker.socket docker
   ls -l /var/run/docker.sock   # should be root:docker 660 again

4. If SELinux is enforcing and still blocks you, check ausearch output above. Do not blanket-disable SELinux; instead relabel or add a targeted policy. As a quick check only:

   getenforce        # Enforcing?
   sudo ausearch -m avc -ts recent | audit2why

5. Prefer rootless Docker as the safer fix. Instead of granting socket access, run Docker rootless so your user owns its own daemon — no privileged group required:

   dockerd-rootless-setuptool.sh install
   export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
   docker info

Security tradeoff — read before adding the docker group

Membership in the docker group is effectively equivalent to root. Anyone in it can run docker run -v /:/host -it alpine chroot /host and own the entire machine. Granting it to a user is granting passwordless root. On shared or production hosts, prefer rootless Docker, or gate Docker behind sudo with an audited command policy, rather than handing out docker group membership freely.

How to Prevent the Issue

• Add operators to the docker group during host provisioning (cloud-init / configuration management) so first login already works — and treat that grant as a root-level privilege grant in your access reviews.
• On multi-tenant and developer-shared hosts, standardize on rootless Docker so no one needs socket access.
• Never chmod 666 /var/run/docker.sock to “fix” this — it exposes root to every local user. Use the group instead.
• Document whether each host is rootful or rootless so users know which socket path is in play.
• Audit docker group membership the same way you audit sudo/wheel membership, because it carries the same blast radius; review it on offboarding and access changes.
• For automation that needs the socket (CI agents, monitoring), run those agents under a dedicated service account in the docker group rather than reusing a human login, so the privilege is scoped and traceable.

Related Docker Errors

• Docker Error: Cannot connect to the Docker daemon
• Docker Error: OCI runtime create failed: runc create failed
• Docker Error: executable file not found in $PATH
• More in the Docker guides.