Containers Intermediate

Fixing ‘Docker daemon socket permission denied’ on Ubuntu 20.04 LTS

Resolve Docker socket permission denied errors on Ubuntu 20.04 LTS when your user isn't in the docker group. Get your containers running swiftly.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Resolve Docker socket permission denied errors on Ubuntu 20.04 LTS when your user isn't in the docker group. Get your containers running swiftly.

When working with Docker on Ubuntu, one of the most common hurdles for new users (and sometimes experienced ones after a fresh install) is the "permission denied" error when trying to interact with the Docker daemon. This typically manifests when attempting to execute docker commands without sudo, indicating that your current user account lacks the necessary permissions to communicate with the Docker Unix socket. This guide will walk you through the precise steps to diagnose and resolve this issue on an Ubuntu 20.04 LTS system.

Symptom & Error Signature

You will encounter this error when attempting to run any docker command that interacts with the Docker daemon, such as docker ps, docker run, or docker images, without prefixing the command with sudo.

The typical error output will look like this:

youruser@yourhost:~$ docker ps
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.

Or, a slightly more concise version:

youruser@yourhost:~$ docker images
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/json": dial unix /var/run/docker.sock: connect: permission denied

Root Cause Analysis

The Docker daemon runs as a service, typically with root privileges, and exposes its API through a Unix socket located at /var/run/docker.sock. By default, this socket is owned by root and the docker group, and its permissions are set to allow read/write access only to root and members of the docker group.

When you install Docker, a system group named docker is created. For security reasons, your standard user account is not automatically added to this group. When you execute a docker command, the Docker client tries to connect to the daemon's Unix socket. If your user is not a member of the docker group, the operating system's permission model prevents the connection, resulting in the "permission denied" error.

Running sudo docker <command> works because sudo temporarily grants your user root privileges, allowing it to bypass the standard permissions and connect to the socket. However, repeatedly using sudo for Docker commands is cumbersome and can be avoided by properly configuring user group memberships.

Step-by-Step Resolution

Follow these steps to correctly add your user to the docker group and resolve the permission denied error.

1. Verify Docker Daemon Status and Socket Location

First, ensure the Docker daemon is running and check the permissions on its Unix socket.

# Check Docker service status
sudo systemctl status docker

# Verify socket permissions
ls -l /var/run/docker.sock

You should see output similar to this, confirming root ownership and docker group ownership with rw permissions for the group:

srw-rw---- 1 root docker 0 Sep 10 14:30 /var/run/docker.sock

2. Check Your Current User's Groups

Next, determine which groups your current user account belongs to. Replace $USER with your actual username, or simply run groups to see the groups for the current logged-in user.

groups youruser

Look for docker in the list of groups. If docker is not present, that's the root cause of your issue.

3. Add Your User to the Docker Group

Use the usermod command to add your user to the docker group. The -a flag appends the user to the specified group without removing them from other groups, and -G specifies the group.

sudo usermod -aG docker youruser

Replace youruser with the actual username you want to grant Docker access to. This command requires sudo as it modifies system user group memberships.

4. Apply Group Changes (Log Out/In or newgrp)

For the group membership changes to take effect, your user's session needs to be re-initialized. The most reliable way to do this is to log out of your current session and then log back in. This ensures that your new group memberships are loaded by the shell.

Alternatively, you can use the newgrp command to temporarily activate the new group in your current shell session without logging out. However, this only affects the current shell and might not propagate to other terminals or services running under your user without a full re-login.

# Option A: Log out and log back in (Recommended for permanent effect)
# Close your terminal, log out of your desktop environment or SSH session, then log back in.

# Option B: Use newgrp (Temporary for current shell)
newgrp docker

Adding a user to the docker group grants them privileges equivalent to the root user on the host system. This is because containers can be used to mount host directories, run privileged processes, or modify system files. Exercise caution and only add trusted users to the docker group.

5. Verify the Fix

After logging back in (or using newgrp docker), verify that your user is now a member of the docker group:

groups youruser

You should now see docker listed among your groups.

Finally, try running a docker command without sudo:

docker ps

If everything is configured correctly, you should now see the list of running Docker containers (or an empty list if none are running) without any permission errors.

youruser@yourhost:~$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

This confirms that your user now has the necessary permissions to interact with the Docker daemon socket.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.