Fix Docker 'permission denied ... /var/run/docker.sock'

Fix Docker 'permission denied ... /var/run/docker.sock'

You run a normal docker command and get slapped with this:

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/...":
dial unix /var/run/docker.sock: connect: permission denied

Almost always this is a permissions problem, not a broken Docker install. Your user account isn't allowed to talk to the daemon. Let's fix it the right way — and understand why the "obvious" fix (sudo) isn't the one you want.

What this error means

The Docker CLI (docker) is a thin client. It doesn't do the real work — it sends commands to the Docker daemon (dockerd) over a Unix socket at /var/run/docker.sock.

That socket file is owned by root and the docker group:

ls -l /var/run/docker.sock
# srw-rw---- 1 root docker 0 Jul  2 09:00 /var/run/docker.sock

Read those permissions: root can read/write, the docker group can read/write, and everyone else gets nothing. So unless you are root or a member of the docker group, the kernel refuses your connection and you get permission denied.

That's the whole story. The fix is getting your user into that group — carefully.

Step 1: See the actual error

Confirm it's really a socket permission issue and not the daemon being down:

1# Does the socket even exist, and who owns it?
2ls -l /var/run/docker.sock
3
4# Is the daemon running?
5sudo systemctl status docker
6
7# What's your current group membership?
8groups
9id

If groups doesn't list docker, that's your problem. If systemctl status docker shows the daemon is inactive or dead, jump to Cause 2.

Cause 1: Your user isn't in the docker group

This is the common case. You installed Docker, and your regular login user was never added to the docker group.

Fix 1: Add your user to the docker group

# Add the current user to the docker group
sudo usermod -aG docker $USER

# Confirm the group now lists your user
getent group docker

The -aG matters: -a means append, -G names the supplementary group. If you forget -a and write sudo usermod -G docker $USER, you'll replace all of your user's supplementary groups with just docker — which can lock you out of sudo and other groups. Always use -aG.

Now the catch that trips everyone up: run docker ps again in the same terminal and it still fails. That's expected.

Group membership is baked into your login session when you authenticate. Your current shell was started before you were added to the group, so it's still running with the old set of groups. The kernel checks the groups your process was launched with — not the group file on disk.

To pick up the new group, either open a fresh login session (log out and back in), or start a new shell that re-reads your groups:

# Start a shell with the docker group applied — no full re-login needed
newgrp docker

# Now this works in that shell:
docker ps

newgrp docker spawns a new shell with docker as the active group. It's the fastest way to verify the fix without logging out. But it only affects that one shell — for the change to apply everywhere (new terminals, your desktop session, tmux panes started earlier), log out and back in once. On a remote box over SSH, disconnect and reconnect.

Cause 2: The Docker daemon isn't running

If the socket doesn't exist at all, or systemctl status docker shows the service stopped, the CLI has nothing to connect to. The error message is sometimes the same "cannot connect" flavor even though the root cause is different.

Fix 2: Start (and enable) the daemon

1# Start the daemon now
2sudo systemctl start docker
3
4# Start it automatically on every boot
5sudo systemctl enable docker
6
7# Verify
8sudo systemctl status docker
9docker info

enable writes the boot symlink so you don't have to start it by hand after every reboot. docker info talking to the daemon successfully means you're good.

Cause 3: Run rootless Docker instead

If you don't want to hand out docker group membership at all — a reasonable stance on shared or security-sensitive machines — run rootless Docker. It runs the daemon as your unprivileged user inside a user namespace, so there's no root-owned socket to gain access to and no group to join.

Fix 3: Set up rootless mode

1# Install the rootless setup (ships with recent Docker Engine)
2dockerd-rootless-setuptool.sh install
3
4# Point your CLI at the rootless socket
5export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
6
7# Persist it in your shell profile
8echo 'export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock' >> ~/.bashrc
9
10# Run the daemon as your user (via systemd --user)
11systemctl --user start docker
12systemctl --user enable docker

Rootless trades a little functionality (some networking and storage-driver limitations) for a much smaller blast radius. It's the right default when a permission error is a symptom of "this user shouldn't have root-equivalent access to begin with."

Cause 4: You just need it working right now

Sometimes you're on a throwaway CI runner or a box you're about to tear down, and you don't care about long-term setup.

Fix 4: Prefix with sudo (stopgap only)

sudo docker ps
sudo docker run hello-world

This works because sudo runs the CLI as root, and root can always reach the socket. But be honest about what this is: a workaround, not a fix. You'll now type sudo before every command forever, scripts that call docker will break, and images built as root can leave root-owned files in bind mounts. Use it to unblock yourself, then do Fix 1 or Fix 3 properly.

Security: the docker group is effectively root

Before you usermod -aG docker every developer on a shared host, understand what you're granting.

Anyone who can talk to the Docker daemon can run a container that bind-mounts the host's root filesystem and read or write anything as root:

# This mounts the entire host filesystem into a container as root
docker run -v /:/host -it alpine chroot /host sh
# ...now you have a root shell on the host.

There's no privilege boundary between the docker group and root. Membership in docker is equivalent to passwordless root on that machine. That's not a bug — it's inherent to how the daemon works.

The practical consequences:

• On your personal laptop, joining the docker group is fine — you already are root there.
• On shared servers, CI hosts, or anything multi-tenant, adding users to docker silently hands them root. Prefer rootless Docker (Fix 3), or gate Docker access behind sudo with an audited policy.
• If you're comparing container runtimes for exactly this reason, rootless-by-default alternatives are worth a look — see the cross-links below.

Quick reference

1# The one-time fix for a personal machine
2sudo usermod -aG docker $USER   # add user to group
3newgrp docker                   # apply in current shell (or log out/in)
4docker ps                       # verify
5
6# If the daemon is down
7sudo systemctl start docker
8sudo systemctl enable docker

Frequently Asked Questions

Why does the error persist after I run usermod?

Because your current shell was started before you joined the docker group, and the kernel checks the groups your process was launched with — not the current contents of the group file. Run newgrp docker to get a shell with the new group, or log out and back in so your whole session reloads.

Is adding my user to the docker group safe?

On a machine where you're already the administrator (your laptop), yes. On shared or multi-tenant hosts, no — docker group membership is equivalent to root, because any member can mount the host filesystem into a container. Use rootless Docker there instead.

What's the difference between newgrp docker and logging out?

newgrp docker only updates the single shell you run it in; other terminals, tmux panes, and your desktop session still have the old groups. Logging out and back in reloads groups for your entire session, which is why it's the durable fix.

Should I just use sudo docker instead?

Only as a temporary unblock. It forces sudo on every command, breaks scripts and tools that call docker directly, and can leave root-owned files in your bind mounts. Fix the group membership or switch to rootless mode for anything you'll use more than once.

How do I avoid the docker group entirely?

Run rootless Docker: dockerd-rootless-setuptool.sh install, then point DOCKER_HOST at unix://$XDG_RUNTIME_DIR/docker.sock. The daemon runs as your unprivileged user in a user namespace, so there's no root-owned socket and no group to join.

See also

• Fix: Docker "no space left on device" — clearing the other error that stops your builds cold
• Docker Image Optimization: A Practical Guide — smaller, faster, safer images
• Docker vs Podman: A Security Comparison — why rootless-by-default matters for the group-is-root problem

Locked out of your own Docker daemon on a shared host? Talk to us at Coding Protocols — we help teams set up secure, rootless container workflows that don't hand out root by accident.

Official References

• Dockerfile best practices — layer caching, image size and build ordering
• Dockerfile reference — every instruction and its semantics