Fix permission denied on the Docker daemon socket

A permission denial while connecting to a Docker Unix socket means the client reached an access boundary it could not cross. For a standard rootful Linux installation, the usual fix is granting a trusted user access through the socket's group. Verify the endpoint and ownership before applying that recipe.

docker context show
ls -l /var/run/docker.sock
id
getent group docker

The common socket is owned by root:docker with group read/write access, but rootless engines and custom setups use other paths or permissions. Use the actual endpoint from your context or environment.

Add a trusted account to the group

On a Linux installation using the docker group:

getent group docker || sudo groupadd docker
sudo usermod -aG docker "$USER"

Log out and back in, then run id and docker info. newgrp docker can start a shell with an updated group context for the current terminal. It does not refresh every existing terminal, desktop session, or service process.

docker run --rm hello-world is an additional execution test, but requires an available image and possibly registry connectivity. A pull failure should not be mistaken for continued socket denial.

Rootful daemon access can provide host-level control. Keep membership restricted to trusted accounts; do not make the socket world-writable as a convenience fix.

Treat ~/.docker errors separately

An error opening ~/.docker/config.json concerns the client's configuration files, not necessarily the daemon socket. Previous elevated commands may have left the wrong owner, but inspect the actual directory first:

ls -ld "$HOME/.docker"
ls -l "$HOME/.docker/config.json"

If this is your own configuration directory and its ownership is incorrect, repair that specific path:

sudo chown -R "$(id -u):$(id -g)" "$HOME/.docker"

Review symlinks and directory contents before a recursive change. The primary group need not have the same name as the user. Do not recursively grant broad group write or execute permission to credential files; restore only the access the owner needs.

Alternatives and service accounts

An authorized sudo docker workflow may fit a managed system, but sudo can use different client configuration and environment. Rootless Engine runs a separate user-owned daemon and requires its own setup, endpoint, and resource planning; it is not merely another group membership setting.

For CI, inspect the runner's actual account. Refresh the running service after changing its group membership, or configure an appropriate supplementary group in its service definition. Do not assume a successful interactive shell proves the service has the same credentials.

FAQ

Why does a new terminal still fail after newgrp?

It may belong to the original login session. Fully refresh the relevant login or service session and compare id output.

Does su versus su - determine Docker access?

The selected account, supplementary groups, environment, and context all matter. Do not infer socket access solely from whether a login shell was requested; inspect the resulting session.

See Docker's Linux post-installation guidance and rootless Engine.