Fix 'Permission Denied' Connecting to Docker Daemon Socket (unix:///var/run/docker.sock)

The 2 AM Wake-Up Call

You're deploying a new service, everything looks good, and then this hits:

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.24/info: dial unix /var%2Frun%2Fdocker.sock: connect: permission denied

You didn't change anything. Docker was working yesterday. Now it isn't. Two commands will tell you exactly what broke — and the fix takes under a minute.

What's Actually Going On

Docker talks to the daemon through a Unix socket at /var/run/docker.sock. That socket is owned by root and the docker group, with mode 660. If your user isn't in the docker group, the OS refuses the connection entirely.

This typically happens when:

A new user account was created without being added to the docker group
You just installed Docker and haven't logged out and back in yet
A CI/CD runner is executing as an unprivileged service account
Someone ran deluser or modified group memberships during a system cleanup

Debug First

Before touching anything, confirm the root cause. Run these in order:

1. Check your current user and groups

whoami
groups

No docker in the output? That's your answer right there.

2. Check the socket permissions

ls -la /var/run/docker.sock

Expected output:

srw-rw---- 1 root docker 0 Mar 17 02:14 /var/run/docker.sock

Owner should be root:docker, mode 660. If you see 600 or a different group, that's your culprit.

3. Verify the docker group exists

getent group docker

No output means the group doesn't exist yet. You'll need to create it before adding anyone to it.

Fix It

Option 1: Add your user to the docker group (permanent fix)

Right call for dev machines and any server where you own the account.

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

# Apply the group change without logging out
newgrp docker

newgrp docker spawns a new shell with the docker group active immediately. Test it:

docker ps

If that works, you're done for this session. Log out and back in to make it stick across all future terminals.

Targeting a specific user instead of yourself:

sudo usermod -aG docker username

Option 2: Fix the socket permissions (emergency stopgap)

Need Docker running right now and can't log out?

sudo chmod 666 /var/run/docker.sock

Takes effect instantly. The tradeoff: every local user on the machine can now control Docker — which is root-equivalent access. Fine on a personal dev box. A real problem on a shared server.

Also: Docker resets this permission on restart, so it isn't a permanent fix.

Option 3: Create the docker group if it doesn't exist

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

Option 4: Use sudo (not recommended long-term)

sudo docker ps

Gets you unblocked in two seconds. Long-term, though, it creates volume permission headaches — files written inside containers end up owned by root on the host. Use this for one-off debugging, not as a daily workflow.

Verify the Fix

Once you've applied the fix, confirm Docker responds without sudo:

# Full connectivity check
docker info

# Expected: server info block with container counts, storage driver, etc.
# Client:
#  Context:    default
#  Debug Mode: false
# Server:
#  Containers: 3
#  Running: 1
#  ...

# Run a container end-to-end
docker run --rm hello-world

Server block in docker info with no errors means the socket connection is clean.

CI/CD and Automation Contexts

Self-hosted runners for GitHub Actions, GitLab CI, or Jenkins usually run as a dedicated service account. Same fix applies — just target that account:

# Find out who the runner runs as
ps aux | grep runner

# Add that user
sudo usermod -aG docker gitlab-runner
sudo systemctl restart gitlab-runner

Docker-in-Docker setups that mount the host socket into a container are a different wrinkle:

docker run -v /var/run/docker.sock:/var/run/docker.sock your-image

The container's user needs to match the GID of the docker group on the host. If the GIDs don't align, you hit the exact same permission wall — just inside the container this time.

Decoding the Permission Bits

When staring at srw-rw---- at midnight and your brain refuses to cooperate, the Unix Permissions Calculator on ToolCraft translates those bits into plain English instantly. Runs in the browser, nothing gets sent anywhere.

Lessons Learned

Bake docker group setup into your provisioning scripts. Ansible, cloud-init, Terraform user data, a manual runbook — doesn't matter which. Add usermod -aG docker as a standard step right after Docker installation. This error almost never appears on properly provisioned machines.
newgrp docker is your best friend here. No logout required. It gives you an immediate group-aware shell to verify the fix before you close anything.
Don't chmod 777 the socket. 666 is already a deliberate tradeoff. 777 adds execute bits that serve no purpose and will flag in any halfway-serious security scan.
Catch CI runner permissions on day one. When standing up a new CI environment, make docker ps the very first pipeline step. Five seconds of validation beats 30 minutes of debugging a failing pipeline a week later.