Fix 'permission denied' on Docker daemon socket (/var/run/docker.sock)

Overview

You tried a Docker command and got:

permission denied while trying to connect to the Docker daemon socket at /var/run/docker.sock

This means your current user lacks permission to access the Docker daemon’s UNIX socket. The quickest workaround is to run docker with sudo, but the correct fix is to grant your user access or align the socket you’re targeting with the daemon you’re running (root or rootless).

Quickstart (most common fix)

• Ensure Docker is installed and the daemon is running.
• Add your user to the docker group, refresh your session, and test.

# 1) Start/enable Docker (Linux, systemd)
sudo systemctl enable --now docker

# 2) Create docker group if missing, then add your user
sudo groupadd -f docker
sudo usermod -aG docker "$USER"

# 3) Apply group change to current shell (or log out/in)
newgrp docker

# 4) Test
docker run --rm hello-world

If this succeeds without sudo, you’re done.

Minimal Working Example

Run a trivial container to confirm permissions and daemon access:

# Immediate workaround (uses root privileges via sudo)
sudo docker run --rm hello-world

# After fixing permissions (no sudo required):
docker run --rm hello-world

Expected: a short message starting with “Hello from Docker!”.

Step-by-step diagnosis

1. Check that the daemon is running

• If the daemon is down, the socket may exist but refuse access or not be present.

# Linux (systemd)
sudo systemctl status docker
# Start it if needed
sudo systemctl start docker

1. Confirm the socket exists and its ownership

ls -l /var/run/docker.sock
# Expected something like: srw-rw---- 1 root docker ... /var/run/docker.sock

• Group should be docker, and your user should be in that group.

1. Add your user to the docker group (canonical fix)

sudo groupadd -f docker
sudo usermod -aG docker "$USER"
# Apply changes
newgrp docker  # or log out and back in

# Validate group membership
id -nG | tr ' ' '\n' | grep -x docker || echo "docker group not active in this shell"

1. Validate the DOCKER_HOST and context

• If DOCKER_HOST points to a different socket, you’ll still fail.

# Show env override
printenv DOCKER_HOST

# Show active context
docker context ls

• Unset DOCKER_HOST if it’s pointing to an unintended socket:

unset DOCKER_HOST

1. Root vs rootless mismatch

• Rootful daemon socket: /var/run/docker.sock (owned by root:docker).
• Rootless daemon socket: $XDG_RUNTIME_DIR/docker.sock (per-user path).

If you run a rootless daemon (dockerd-rootless-setuptool.sh install), connect to your user’s socket:

export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

If you run the classic rootful daemon, ensure you’re targeting /var/run/docker.sock and are in the docker group.

1. SELinux-aware fix (Fedora/RHEL/CentOS) If labels are wrong, access can be denied even with correct groups.

# Restore default labels for runtime dirs
sudo restorecon -RFv /var/run
# If needed, specifically for Docker paths
sudo restorecon -v /var/run/docker.sock

Avoid disabling SELinux; fix labels instead.

1. Systemd override to keep correct group on the socket If the socket ownership keeps resetting on reboot, confirm systemd units:

sudo systemctl cat docker.socket
sudo systemctl cat docker.service

If needed, enforce group via an override:

sudo systemctl edit docker.socket

Paste the following, save, then reload:

[Socket]
SocketGroup=docker

sudo systemctl daemon-reload
sudo systemctl restart docker.socket docker.service

1. WSL2 notes (Windows with Linux distribution)

• Start Docker inside the distro if you installed the Linux engine there:

sudo service docker start   # or: sudo systemctl start docker
sudo usermod -aG docker "$USER" && newgrp docker

• If using Docker Desktop for Windows, typically use the desktop-provided context rather than managing a separate Linux daemon.

1. Docker Desktop on macOS/Windows

• The Linux path /var/run/docker.sock refers to the Desktop VM. Use the default context provided by Docker Desktop or set DOCKER_HOST to that context. Local Linux socket on the host OS will not exist on Windows/macOS terminals unless using the Docker-provided environment.

1. Snap vs package-manager installs

• Prefer one installation method. Mixed installs can leave stale sockets or services.

# Check which docker binary you’re running
which docker
# List installed packages and snaps
snap list | grep -i docker || true
rpm -qa | grep -i docker || dpkg -l | grep -i docker || true

Remove duplicates and keep a single, consistent install.

Pitfalls and security notes

• Don’t chmod 666 /var/run/docker.sock. It grants any local user root-equivalent Docker access.
• docker group is powerful: members can effectively gain root on the host via container features. Add only trusted users.
• Remember to re-login or run newgrp docker after usermod.
• Avoid mixing rootless and rootful daemons in the same shell without setting/clearing DOCKER_HOST.
• Containers launched with sudo won’t be visible to docker ps run without sudo if you’re talking to different sockets.
• In CI or ephemeral environments, ensure the agent user is in the docker group before running builds.

Performance notes

• Using the docker group vs sudo has no meaningful performance impact.
• Rootless Docker introduces slight networking overhead (user-mode networking) and may be slower for heavy I/O, but often acceptable for development.
• Excessive logging from repeated permission failures can clutter journals; fix the root cause rather than suppressing logs.

Verification checklist

• Docker daemon active: systemctl is-active docker returns active.
• Socket ownership correct: group docker on /var/run/docker.sock.
• User in docker group: id -nG includes docker.
• No conflicting DOCKER_HOST or contexts.
• docker run --rm hello-world works without sudo (if using rootful + docker group) or with the proper rootless socket.

Tiny FAQ

• Why does sudo make it work? Because root can access the socket regardless of group membership.

• Do I have to reboot? No. Use newgrp docker or log out and log back in.

• Is adding my user to docker group safe? It grants root-equivalent access via Docker. Restrict membership to trusted users.

• How do I revert the change? Remove the user from the group and restart Docker:

sudo gpasswd -d "$USER" docker
sudo systemctl restart docker

• I’m using rootless Docker. What’s the socket? It’s usually at $XDG_RUNTIME_DIR/docker.sock. Set DOCKER_HOST accordingly.