Investigate a Docker permission denial by the failing path

Read the denied path and operation before changing permissions. A failure to connect to a daemon socket differs from an error reading ~/.docker/config.json or writing a mounted application directory. Each belongs to a different access boundary.

Confirm the intended endpoint

docker context show
docker context ls
id

Check environment and command-line overrides. A socket outside /var/run/docker.sock may belong to a local rootless or Desktop engine; it does not automatically mean a remote host. Use the selected socket's actual permissions rather than applying the rootful Linux defaults everywhere.

For a conventional rootful Linux installation, inspect:

ls -l /var/run/docker.sock
getent group docker

If that socket deliberately grants access to the docker group, add only the intended trusted account, then refresh its login or service session. Rootful daemon access can provide host-level control; making the socket mode 0666 exposes that capability to other local users.

Compare account membership with live credentials

An account may have been added to a group while an existing process still holds its old supplementary-group list. id without a username shows the current session's credentials. A fresh login or newgrp docker can update the relevant shell; CI runners and other long-running services may need a deliberate restart under their actual service account.

Do not use a substring match on groups output as proof of exact group membership, or automatically modify groups as part of a read-only diagnostic command.

Inspect client files separately

If the error names the user's Docker configuration, inspect its owner, mode, ACLs, and parent-directory access. Previous elevated commands can leave root-owned files, but that is a condition to verify. Repair only the intended user's configuration path; use the actual numeric UID and primary GID rather than assuming the user and group names match. Credential-bearing files do not need broad recursive group write access.

Check container and SELinux boundaries

A non-root process inside a container that uses a mounted daemon socket needs permissions matching the socket's numeric ownership. Merely creating a group named docker is insufficient if the GID differs. User namespaces, rootless operation, and isolation settings can also matter; container root is not a universal bypass.

On SELinux systems, use the actual denial records:

getenforce
sudo ausearch -m avc -ts recent

For appropriate bind mounts, :z and :Z can request shared or private labeling. They are not universal fixes for socket access, and relabeling broad host system paths can cause damage. Match the policy change to the verified denial.

FAQ

Is rootless Docker a drop-in fix?

It is a separate user-owned daemon model with prerequisites, a different endpoint, and resource/network considerations. Follow its installation guide rather than running the setup tool blindly. Existing rootful images and containers are not automatically moved into that daemon.

Why does sudo work?

It may change access, but also environment, home-directory configuration, and selected context. Compare the actual daemon destinations before concluding that group membership is the only issue.

Can I permanently chmod the socket?

That bypasses intended access controls and may be overwritten when the daemon recreates it. Configure authorized access through the supported daemon and service setup instead.

See Linux post-installation, rootless mode, and bind mounts.