Fix docker ps Permission Denied on Linux: Docker Group and Daemon Checks

If docker ps returns permission denied after installation while sudo docker ps works, check the user permissions first. With a standard Linux Docker Engine, a regular user needs sudo or membership in the docker group to access the Docker socket.

A Cannot connect to the Docker daemon error can mean the service is stopped or the CLI is targeting a different endpoint. These commands apply to a rootful Docker Engine on Linux with systemd. Docker Desktop and Rootless Docker use different service and socket arrangements.

On this page

Start with the error message

docker ps asks the Docker daemon for the running container list; it does not start Docker. Checking CLI installation, daemon state, and user access separately helps identify the failed step.

Observed result	First check
docker: command not found	CLI installation and the executable search path (PATH)
permission denied mentioning docker.sock	Socket permissions and the groups in the current session
Cannot connect to the Docker daemon	Daemon state and connection endpoint
Table header with no error	Whether the query succeeded with no running containers

Check whether the CLI is available with the following commands. Output from docker --version does not prove the daemon is running.

command -v docker
docker --version

If the command cannot be found, check the distribution and installed packages against the Docker Engine installation documentation. Group membership cannot fix a missing executable.

For permission denied, inspect the socket

A standard local Engine accepts requests through the Unix socket /var/run/docker.sock. It commonly belongs to user root and group docker, with read/write access for the owner and group. Inspect the actual configuration:

ls -l /var/run/docker.sock
id -nG
docker ps
sudo docker ps

If the socket belongs to root:docker, has permissions srw-rw----, and your current group list lacks docker, access can be denied. Success with sudo docker ps supports a permissions diagnosis. However, sudo can use different user settings, so confirm both commands target the same socket.

If the socket does not exist, continue to the service and endpoint checks below. Error wording and socket paths can vary by installation and version.

Add the intended user to the docker group

Membership in the docker group allows administrator-level actions on the host through Docker. Grant it only to trusted operator accounts; see the Docker security documentation. The daemon remains rootful when a regular user runs the CLI this way. To run the daemon without root privileges, evaluate Rootless mode.

1. Confirm the account and group

Run these commands in a terminal logged in as the regular user who will use Docker. Confirm that whoami prints the intended account.

whoami
getent group docker

Skip group creation if getent group docker returns an entry. If it returns nothing and local accounts are used, create the group:

sudo groupadd docker

2. Append the group without removing existing memberships

sudo usermod -aG docker "$USER"

-G docker specifies a supplementary group, and -a appends it while retaining existing memberships. Omitting -a can remove memberships not named in the command. The usermod manual explains these options.

The command above assumes $USER is the regular user who will run Docker. In a root shell entered with sudo -i or su -, the target may be root. When administering another account, replace maru below with the actual username. Omit sudo if already in a root shell.

sudo usermod -aG docker maru

3. Log out and back in

The account database records the new membership, but an existing shell does not immediately acquire the new group permissions. Reconnect SSH or log out of the desktop session and back in. A new terminal tab inside an existing terminal or IDE may inherit the old groups.

To check within the current terminal, you can start a subshell with the docker group. Files created in that subshell may belong to group docker, so keep that behavior in mind.

newgrp docker
id -nG
docker ps

If id -nG includes docker and docker ps succeeds, that shell can access Docker. Leave the newgrp subshell with exit. Other terminals and existing programs keep their current permissions. These steps follow Docker’s Linux post-installation guide.

For Cannot connect, check the service and endpoint

Some installations do not start the service automatically after the Docker Engine packages are installed. For a standard Linux Engine, inspect its state:

sudo systemctl status docker --no-pager

active (running) means the service is running. If it is stopped and this host’s Engine is the intended target, start it and query again.

sudo systemctl start docker
sudo systemctl is-active docker
sudo docker ps

start starts the service now. To start it automatically at boot as well, run sudo systemctl enable docker separately. enable alone does not start a stopped service.

If startup fails, read the error log before retrying. Investigate the condition identified there, such as a configuration conflict or insufficient storage.

sudo journalctl -u docker.service -b -n 100 --no-pager

If the result is Unit docker.service could not be found, check whether that service is installed. A CLI-only installation, Docker Desktop, or Rootless Docker may use a different service. For Rootless Docker, run systemctl --user status docker as the relevant user. The systemd and journalctl guide (Korean) covers service registration and log inspection.

If the service runs but the CLI still cannot connect, inspect the target daemon. A context stores connection settings, and environment variables can override the selected endpoint.

docker context ls
printenv DOCKER_HOST DOCKER_CONTEXT

Apply the following settings only after confirming that the standard local Engine is the intended target. They do not apply to an intentional remote, Docker Desktop, or Rootless connection.

unset DOCKER_HOST DOCKER_CONTEXT
docker context use default
docker ps

unset clears variables only in the current shell. If they return after logging in again, inspect shell startup files or the IDE environment. Docker documents endpoint diagnosis in its daemon troubleshooting guide and contexts guide.

When permissions still fail after adding the group

Compare the groups active in the current shell with those recorded for the account. With no username argument, id reports the current process credentials. Run these commands in the intended regular user’s shell.

id -nG
id -nG "$USER"
ls -l /var/run/docker.sock

If the username-specific result includes docker but the first result does not, the session still has its previous permissions. Log out fully and back in, or test with newgrp docker. If neither includes docker, check whether the group was added to a different account.

If both lists include docker, compare the socket path in the error with its actual owning group. Nonstandard permissions require inspecting the Docker service, socket configuration, and installation method. Do not grant every local user access by applying chmod 666 or chmod 777 to docker.sock.

If the error names ~/.docker/config.json, inspect the user configuration permissions rather than the daemon socket. Check ownership with ls -ld "$HOME/.docker" "$HOME/.docker/config.json". If earlier sudo use changed ownership, follow the Docker guide’s user configuration permissions instructions to correct the affected directory.

An empty container list can be a successful result

If docker ps prints the table header without an error, the target daemon has no running containers. Add -a to include stopped containers.

docker ps
docker ps -a

A container such as hello-world can exit after running and remain visible only in the full list. The docker ps reference defines the default as running containers. If containers repeatedly show Restarting, continue with the container restart and log guide (Korean).

After adding the group, verify id -nG and docker ps in a newly logged-in regular user session. Successful access and the presence of running containers are separate checks.