Containers Intermediate

Docker Daemon Permission Denied: User Not in Docker Group on Alpine Linux

Resolve 'permission denied' when interacting with Docker on Alpine Linux due to a user not being in the 'docker' group, causing daemon socket access issues.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Resolve 'permission denied' when interacting with Docker on Alpine Linux due to a user not being in the 'docker' group, causing daemon socket access issues.

When working with Docker on Alpine Linux, encountering a "permission denied" error when trying to execute docker commands is a common hurdle for new and experienced users alike. This issue typically manifests as an inability to interact with the Docker daemon socket, preventing you from running containers, inspecting images, or managing your Docker environment without resorting to su or sudo. This guide will walk you through the precise steps to resolve this on Alpine Linux systems.

Symptom & Error Signature

Users attempting to run any docker command (e.g., docker ps, docker images, docker run) will receive an error message indicating a permission problem accessing the Docker daemon's Unix socket.

$ docker ps
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/containers/json?all=1": dial unix /var/run/docker.sock: connect: permission denied

This error explicitly states that the current user lacks the necessary permissions to communicate with the Docker daemon, which operates via the /var/run/docker.sock socket.

Root Cause Analysis

The Docker daemon runs as the root user and manages containers, images, volumes, and networks. To facilitate secure communication, it exposes its API through a Unix domain socket, usually located at /var/run/docker.sock.

By default, this socket is owned by the root user and the docker group, with specific file permissions (srw-rw----). This means:

  • Only the root user can access the socket with full read/write permissions.
  • Any user explicitly added to the docker group can also access the socket with full read/write permissions.
  • No other users have access to this socket.

When Docker is installed on Alpine Linux, the installer typically creates the docker group. However, it does not automatically add your current user to this group. Therefore, if your user account is not a member of the docker group, any attempt to interact with the Docker daemon will result in the "permission denied" error, as your user lacks the necessary privileges to read or write to the /var/run/docker.sock file.

Step-by-Step Resolution

Follow these steps to correctly configure your user's permissions and resolve the Docker daemon socket access issue on Alpine Linux.

1. Verify Current User and Docker Group Membership

First, confirm your current user's group memberships and inspect the permissions of the Docker socket.

# Check your current username
$ whoami

# Check groups your current user belongs to
$ id -Gn

# Verify if the 'docker' group exists and who its members are (if any)
$ cat /etc/group | grep docker

# Inspect the permissions of the Docker daemon socket
$ ls -l /var/run/docker.sock

You should typically see output similar to this for the socket:

srw-rw---- 1 root docker 0 Oct 26 14:30 /var/run/docker.sock

This confirms the socket is owned by root and the docker group, with read/write permissions for both.

2. Add Your User to the Docker Group

This is the core step to resolve the permission issue. You need to add your user account to the docker group. This operation requires root privileges.

Replace <your_username> with your actual username (e.g., myuser).

# Option 1: Using 'su' to become root, then add the user
# This is common on minimal Alpine installations without sudo
$ su -
# Now you are root. Run:
# adduser <your_username> docker
# Then exit root session:
# exit

# Option 2: Using 'sudo' (if installed and configured on your Alpine system)
# sudo adduser <your_username> docker

Adding a user to the docker group grants them root-equivalent privileges on the host system. Members of the docker group can run containers with arbitrary root access, manipulate host filesystems, and potentially escalate privileges. Only add trusted users to this group.

For the group membership change to take effect, you must log out of your current session and log back in. Simply opening a new terminal tab or using su - <your_username> will not suffice, as your session's group list is inherited at login.

3. Verify Group Membership After Re-login

After logging out and logging back into your Alpine Linux session, verify that your user is now correctly a member of the docker group.

$ id -Gn

Your output should now include docker among the listed groups. If it doesn't, ensure you logged out and back in properly.

4. Test Docker Functionality

With your user successfully added to the docker group and after re-logging in, you should now be able to execute docker commands without any permission errors.

$ docker ps
# You should see an empty list of containers or your running containers
# CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

$ docker run hello-world
# This should download and run the 'hello-world' container successfully
# Hello from Docker!
# This message shows that your installation appears to be working correctly.
# ... (rest of hello-world output)

If these commands execute successfully, you have successfully resolved the "Docker daemon socket permission denied" error on your Alpine Linux system.

👨‍💻

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.