}

Fix Docker 'Permission Denied' Error (2026) — All Causes

Last updated: 6 min read

Got permission denied while trying to connect to the Docker daemon socket

Last updated: March 2026

This error means your user account does not have permission to communicate with the Docker daemon. The fix in most cases is to add your user to the docker group with sudo usermod -aG docker $USER, then log out and back in (or run newgrp docker). Read on for all causes, the security implications of each fix, and the rootless Docker alternative.

The Full Error Message

You see one of these when running any docker command as a non-root user:

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/create": dial unix /var/run/docker.sock: connect: permission denied

Or the shorter variant:

docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

Why Does This Happen?

The Docker daemon (dockerd) runs as root and exposes a Unix socket at /var/run/docker.sock. By default, only the root user and members of the docker group can access this socket. When your user is not in the docker group, every docker command fails with a permission error.

Check the current socket permissions:

ls -la /var/run/docker.sock

Typical output:

srw-rw---- 1 root docker 0 Mar 26 10:00 /var/run/docker.sock

The rw for the group means the docker group has read/write access. Add your user to that group and the error goes away.

Fix 1: Add Your User to the docker Group (Recommended)

This is the standard fix for developers and administrators who regularly use Docker.

# Add the current user to the docker group
sudo usermod -aG docker $USER

Then apply the group change without logging out:

newgrp docker

Or log out and back in completely — the group membership is applied at login. Verify it worked:

# Check your group memberships
groups

# Test Docker without sudo
docker run hello-world

On Ubuntu 22.04 / 24.04 and Debian 12:

sudo usermod -aG docker $USER
newgrp docker
docker ps

On RHEL 9 / CentOS Stream 9 / Fedora:

sudo usermod -aG docker $USER
# Log out and back in, or:
newgrp docker

Adding another user (not yourself):

sudo usermod -aG docker alice
# alice must log out and back in for the change to take effect

Fix 2: Use newgrp to Activate the Group in the Current Session

After running usermod, the group change is not active in your current shell session. newgrp starts a new shell with the updated group applied immediately — no logout required:

sudo usermod -aG docker $USER
newgrp docker
docker ps   # works without sudo

newgrp docker only affects the current terminal session. Open a new terminal and the group is active there too once you've run usermod and your session was started after the usermod call.

Fix 3: Fix Socket Permissions (Temporary — Not Recommended for Production)

If you need a quick one-time fix without modifying group membership:

sudo chmod 666 /var/run/docker.sock

This makes the socket world-readable/writable so any user can access Docker. The change is lost after a Docker restart. This approach is sometimes used in CI/CD container runners, but avoid it on shared systems — it gives every user on the machine root-equivalent Docker access.

Fix 4: Use sudo for Docker Commands (Simple but Cumbersome)

If you cannot or do not want to modify group memberships:

sudo docker ps
sudo docker run hello-world
sudo docker build -t myapp .

This works immediately with no configuration changes. For occasional use or scripted environments where you control the sudo configuration, this is acceptable. For daily development work, it is tedious and you should prefer Fix 1.

To allow a user to run Docker with sudo without a password prompt, add to /etc/sudoers via visudo:

alice ALL=(ALL) NOPASSWD: /usr/bin/docker

Fix 5: Use Rootless Docker (Most Secure Option)

Rootless Docker runs the entire Docker daemon as a non-root user. The daemon and all containers run without root privileges, significantly reducing the security attack surface.

Install rootless Docker (Ubuntu/Debian):

# Install dependencies
sudo apt install -y uidmap dbus-user-session

# Install rootless Docker
dockerd-rootless-setuptool.sh install

Enable and start:

systemctl --user enable docker
systemctl --user start docker

Set the required environment variables:

export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
# Add to ~/.bashrc or ~/.zshrc to make permanent
echo 'export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock' >> ~/.bashrc

Test rootless Docker:

docker run hello-world

Rootless Docker has some limitations: port numbers below 1024 require additional configuration, and some storage drivers are not supported. For most development use cases it works perfectly.

Why Giving Users Docker Group Access Is Equivalent to sudo

This is important to understand before adding users to the docker group on a shared or production system:

The docker group gives full control of the Docker daemon, which runs as root. A user in the docker group can:

# Mount the host filesystem into a container and get root shell
docker run -v /:/host -it ubuntu chroot /host bash
# Now you have root access to the entire host filesystem

Or read any file on the host:

docker run -v /etc/shadow:/tmp/shadow ubuntu cat /tmp/shadow

The docker group is effectively a root group. On multi-user systems, only add trusted administrators. On single-user developer workstations, it is safe and convenient.

Alternatives for reducing risk: - Use rootless Docker (Fix 5) - Use Podman (daemonless, rootless by default) - Use sudo with explicit allowlists in sudoers

Verify the docker Group Exists

On a fresh Docker installation the docker group is created automatically. Check:

getent group docker

Expected output:

docker:x:999:alice,bob

If the group does not exist (unusual but possible on some minimal installations):

sudo groupadd docker
sudo usermod -aG docker $USER
sudo systemctl restart docker
newgrp docker

Permission Denied in Docker-in-Docker (DinD) / CI Environments

In GitLab CI, GitHub Actions, or Jenkins pipelines running inside Docker containers, the permission error often occurs because the CI runner user is not in the docker group of the host.

GitLab CI with Docker socket binding:

# .gitlab-ci.yml
build:
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t myapp .

GitHub Actions:

- name: Build Docker image
  run: docker build -t myapp .
  # GitHub Actions runners already have Docker access configured

For Jenkins running in a Docker container with socket binding:

docker run -v /var/run/docker.sock:/var/run/docker.sock \
           -u root \
           jenkins/jenkins:lts

Running Jenkins as root inside the container gives it access to the host Docker socket. Alternatively, find the GID of the docker group on the host and set that as the supplementary group for the Jenkins container.

Related Articles

FAQ

Q: I added my user to the docker group but still get the error. What's wrong? Group changes do not take effect in your current session. Either run newgrp docker to activate the group in the current terminal, or log out and log back in completely. Running id should show docker in your groups list after the change is active.

Q: Can I use Docker without installing it as root at all? Yes — rootless Docker and Podman both run entirely without root privileges. Rootless Docker is installed per-user with dockerd-rootless-setuptool.sh install. Podman is available on Fedora, RHEL, and Ubuntu and is rootless by default with no daemon required.

Q: Is it safe to add a service account to the docker group for CI/CD? On a dedicated CI/CD build host where the service account is controlled by the CI system, yes. On a shared server where other teams also have accounts, consider using rootless Docker or a dedicated build host instead. Remember that docker group membership equals effective root access to the host.