permission denied while trying to connect to the Docker daemon socket
Quick fix
Start Docker and make sure your user has permission to access the Docker daemon.
Updated
Verification status
General troubleshooting guidance
Evidence
0 public source URLs
Before you change production
This page does not expose source URLs in the page body. Treat it as general troubleshooting guidance and verify against official documentation before changing systems.
Reproduce the smallest failing action and save non-secret logs before changing configuration.
Check versions for Docker, related SDKs, package managers, CI runners, and hosting providers.
Change one setting or dependency at a time, then rerun the same failing command or request.
Avoid destructive commands, credential rotation, billing changes, or security relaxations without a rollback plan.
What this error means
Docker permission denied errors mean the Docker client, daemon, or container process tried to access a file, socket, or directory without enough operating system permissions.
Common causes
The Docker daemon is not running.
Your Linux user is not in the docker group.
The Docker socket is owned by root and the command is running as an unprivileged user.
A bind mount maps host files that the container user cannot read or write.
Quick fixes
Confirm Docker is running:
docker version
On Linux, add your user to the Docker group:
sudo usermod -aG docker "$USER"
Log out and back in so the group change applies.
Retry the Docker command.
Step-by-step troubleshooting
Run docker info and check whether the daemon responds.
Inspect /var/run/docker.sock ownership with ls -l /var/run/docker.sock.
If the failure happens inside a container, check the container user with id.
For bind mounts, compare host file ownership with the UID and GID used in the container.
Avoid using sudo as a permanent workaround for development workflows; fix the daemon or file permissions instead.
Diagnostic flow for this page
Match permission denied while trying to connect to the Docker daemon socket exactly before applying the quick fix.
Compare the failing environment with Docker versions, account scope, provider settings, and deployment context.
Check the listed common causes in order, starting with the cause that best matches your logs.
Use the evidence status below to decide whether to confirm against public sources or official documentation.
Apply one reversible change, rerun the smallest failing action, and keep rollback notes.