Introduction

docker.sock permission denied means the Docker CLI found the socket but the current user or process is not allowed to talk to it. The fix is rarely to chmod 777 the socket. You usually need to align socket ownership, user group membership, or rootless Docker expectations instead.

Symptoms

  • docker ps returns permission denied on /var/run/docker.sock
  • Commands work with sudo but fail for the normal user
  • The issue appears after reinstalling Docker or switching users
  • CI or systemd jobs fail even though interactive shells work

Common Causes

  • The user is not in the docker group
  • The process is running under a different user context than expected
  • Rootless Docker is configured, but the client is pointed at the rootful socket
  • Socket ownership or service startup state drifted after an update

Step-by-Step Fix

  1. 1.Inspect the socket permissions
  2. 2.Confirm who owns the socket and which group has access.
bash
ls -l /var/run/docker.sock
id
  1. 1.Check docker group membership
  2. 2.If the socket is group-owned by docker, the current user must be in that group and start a fresh session.
bash
getent group docker
groups
  1. 1.Verify whether you are using rootless Docker
  2. 2.Rootless setups use a different socket path and should not be debugged as if they were rootful.
bash
echo $DOCKER_HOST
docker context ls
  1. 1.Restart the service or the user session after changes
  2. 2.Group membership and socket ownership fixes do not always apply to existing sessions.
bash
sudo systemctl restart docker
newgrp docker

Prevention

  • Use group membership and context fixes instead of unsafe world-writable sockets
  • Document rootless vs rootful Docker per host
  • Test Docker access from the same user context your jobs actually run under
  • Recheck socket ownership after Docker upgrades or service changes