How to Fix “Permission Denied” When Connecting to the Docker Daemon (Beginner Guide)

If you run Docker commands and see an error like:

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

…you’re not alone. This is one of the most common beginner Docker problems on Linux.

This tutorial explains what the error means, why it happens, and multiple safe ways to fix it. You’ll also learn how to verify your fix and avoid common pitfalls.

Table of Contents

• 1) What this error actually means
• 2) Quick diagnosis checklist
• 3) Fix option A (recommended): Add your user to the docker group
• 4) Fix option B: Use sudo (simple, but less convenient)
• 5) Fix option C: Rootless Docker (no daemon socket permissions issue)
• 6) Fix option D: Correct the socket permissions (usually not recommended)
• 7) Fix option E: Docker Desktop / macOS / Windows notes
• 8) Common causes and how to identify them
• 9) Verify Docker is working (real test commands)
• 10) Security notes (important)
• 11) Troubleshooting: still getting permission denied?

1) What this error actually means

On most Linux systems, Docker uses a daemon (a background service) called dockerd. Your docker command-line tool (the Docker CLI) talks to that daemon.

By default, the Docker CLI connects to the daemon through a Unix socket:

• Socket path: /var/run/docker.sock
• Connection type: local IPC (inter-process communication), not a network port

When you run:

docker ps

the CLI tries to open /var/run/docker.sock. If your user does not have permission to read/write that socket, you get a “permission denied” error.

A typical message looks like:

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

Why a socket needs permissions

A Unix socket is like a special file. It has an owner, a group, and file permissions (read/write/execute bits). Docker typically sets the socket to:

• Owner: root
• Group: docker
• Permissions: allow members of the docker group to access it

So the core idea is:

If your user is not root and not in the docker group, you can’t talk to the Docker daemon.

2) Quick diagnosis checklist

Before changing anything, gather facts. Run these commands:

2.1 Check whether Docker is installed and the daemon is running

docker --version

Then check the service:

sudo systemctl status docker

If it’s not running, start it:

sudo systemctl start docker
sudo systemctl enable docker

2.2 Check socket ownership and permissions

ls -l /var/run/docker.sock

Common output:

srw-rw---- 1 root docker 0 Apr 15 10:20 /var/run/docker.sock

Interpretation:

• root owns it
• group is docker
• group has read/write (rw)
• “others” have no access (---)

2.3 Check if your user is in the docker group

groups

or more specifically:

id -nG "$USER"

If you do not see docker listed, that’s the main reason for the error.

3) Fix option A (recommended): Add your user to the docker group

This is the most common fix on Linux. It allows you to run Docker commands without sudo.

3.1 Create the docker group (if it doesn’t exist)

Many installations already create it, but it’s safe to run:

sudo groupadd docker

If it already exists, you may see:

groupadd: group 'docker' already exists

That’s fine.

3.2 Add your user to the group

Replace $USER if needed:

sudo usermod -aG docker "$USER"

Explanation:

• usermod modifies user accounts
• -aG means “append to supplementary groups”
  • Important: Don’t use -G without -a, or you might remove your user from other groups.

3.3 Apply the new group membership

Group changes usually require you to log out and log back in. Alternatives:

Option 1: Log out / log in (most reliable)

Do that, then test again.

Option 2: Start a new shell with the group applied

You can run:

newgrp docker

This starts a new shell where your primary group becomes docker (for that shell session). Then test Docker commands inside that shell.

3.4 Test

docker ps

If it works, you’re done.

4) Fix option B: Use sudo (simple, but less convenient)

If you don’t want to change group membership, you can run Docker commands as root:

sudo docker ps

This works because root can access /var/run/docker.sock.

When is sudo docker ... a good idea?

• On servers where you want strict control over who can use Docker
• In scripts run by root
• When you don’t want to grant users Docker access (see Security notes)

Downsides

• You must type sudo often
• Files created by containers may become owned by root on the host (depending on volumes and operations), which can be annoying

5) Fix option C: Rootless Docker (no daemon socket permissions issue)

Rootless Docker runs the daemon and containers without root privileges. This can avoid the “permission denied on /var/run/docker.sock” problem because it uses a user-owned socket (often under your home directory).

Rootless mode is a bigger topic, but here’s a practical starting point on many Linux distributions.

5.1 Install rootless dependencies (varies by distro)

On Debian/Ubuntu, you might need:

sudo apt-get update
sudo apt-get install -y uidmap dbus-user-session slirp4netns fuse-overlayfs

5.2 Install / set up rootless Docker

If Docker is installed from official packages, you may have:

dockerd-rootless-setuptool.sh install

Then enable lingering so your user services can run without logging in (optional but common):

sudo loginctl enable-linger "$USER"

5.3 Use the rootless context

Rootless Docker often sets environment variables like DOCKER_HOST or creates a Docker context. Check:

docker context ls
docker context use rootless

5.4 Verify

docker info

Look for lines indicating rootless mode.

Notes

• Rootless Docker can have networking and port-binding limitations (e.g., binding to ports <1024 may require extra configuration).
• For beginners, the docker group method is usually simpler, but rootless is great if you want to avoid “Docker group == root” risk (explained later).

6) Fix option D: Correct the socket permissions (usually not recommended)

You might see advice online like:

sudo chmod 666 /var/run/docker.sock

This makes the socket world-readable and world-writable, meaning any local user can control Docker. That’s generally a bad idea.

Why it “works”

Because it gives everyone permission to connect to the daemon socket.

Why it’s risky

If any user can access Docker, they can effectively gain root-equivalent control over the machine (see Security notes).

If you must adjust permissions, do it properly

The correct long-term approach is to ensure the socket is owned by root:docker and has 660 permissions:

sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock

But note:

• Docker typically manages this socket itself when the daemon starts.
• If your changes don’t persist across reboots, that’s expected.

If the socket is being created with unexpected permissions, you may have a misconfiguration in the Docker service unit or an override file. Check:

systemctl cat docker

Look for custom ExecStart lines or socket options.

7) Fix option E: Docker Desktop / macOS / Windows notes

The classic /var/run/docker.sock permission issue is mainly a Linux issue.

macOS / Windows with Docker Desktop

• Docker Desktop runs Docker inside a VM.
• The CLI integrates with it.
• If you see permission issues, they’re often related to:
  • running Docker commands inside a Linux VM/WSL without correct setup
  • file sharing permissions
  • using the wrong Docker context

Check contexts:

docker context ls
docker context use default

WSL2 (Windows Subsystem for Linux)

Depending on how you installed Docker:

• If using Docker Desktop integration with WSL2, the daemon may not be local in the same way.
• If you installed Docker Engine inside WSL2, then the Linux instructions in this guide apply.

8) Common causes and how to identify them

“Permission denied” can happen for a few different reasons. Here are the most common ones and how to confirm each.

Cause 1: Your user is not in the docker group

Symptoms:

• ls -l /var/run/docker.sock shows group docker
• groups does not include docker

Fix: Add user to docker group (Option A).

Cause 2: Docker daemon is not running

Symptoms:

• You may see a different error like “Cannot connect to the Docker daemon”
• systemctl status docker shows inactive/failed

Fix:

sudo systemctl start docker

Then re-test.

Cause 3: You’re using sudo sometimes and non-sudo other times (confusing contexts)

Symptoms:

• sudo docker ps works
• docker ps fails

Fix: Add user to docker group or use sudo consistently.

Cause 4: Wrong DOCKER_HOST environment variable

If DOCKER_HOST points somewhere unexpected, you might see permission errors or connection failures.

Check:

echo "$DOCKER_HOST"

Typical defaults:

• empty (Docker uses /var/run/docker.sock)
• unix:///var/run/docker.sock

If it points to something else (like a TCP socket or a different unix socket), you may be connecting to a socket you can’t access.

To temporarily unset:

unset DOCKER_HOST
docker ps

Cause 5: You’re inside a container trying to access Docker

Inside a container, /var/run/docker.sock may not exist, or may be mounted with permissions you don’t have.

Check:

ls -l /var/run/docker.sock

If you are intentionally using “Docker-in-Docker” or “Docker socket mount”, you may need to mount the socket and ensure the container user has permissions. Example (host command):

docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker:cli docker ps

Even then, if the container user isn’t in a group matching the socket’s group ID, you can still get permission errors. That’s an advanced scenario; beginners should usually run Docker commands on the host.

Cause 6: SELinux/AppArmor restrictions

On some systems (Fedora/RHEL/CentOS with SELinux), you can run into access issues that look like permission problems.

Check SELinux status:

getenforce

If it’s Enforcing and you suspect policy issues, check audit logs. But in most beginner cases, the docker group fix is the right one.

9) Verify Docker is working (real test commands)

After applying your fix, verify with a few concrete commands.

9.1 Confirm your group membership

id "$USER"

Look for docker in the groups list.

9.2 Check Docker can talk to the daemon

docker info

If it prints server info (storage driver, cgroup driver, etc.), your connection works.

9.3 Run a test container

The classic test:

docker run --rm hello-world

Expected behavior:

• Docker pulls the image if needed
• Runs a container that prints a message
• Exits and removes the container (--rm)

9.4 List containers/images

docker ps
docker ps -a
docker images

If these work without sudo, your permissions are correct.

10) Security notes (important)

Adding your user to the docker group is convenient, but you should understand the security implications.

Docker group is effectively root

Members of the docker group can typically gain root-level access to the host. Why?

Because Docker lets you run containers with:

• mounted host filesystem
• privileged mode
• access to host devices
• the ability to change file ownership/permissions via mounts

For example, a user with Docker access can often do something like:

docker run --rm -it -v /:/host alpine chroot /host /bin/sh

If permitted, that gives a shell with host filesystem access (effectively root). The exact behavior depends on system configuration, but the general rule is widely accepted:

If you can control Docker, you can usually control the machine.

What to do about it

• On personal dev machines: adding yourself to docker is common and acceptable.
• On multi-user servers: restrict Docker access; prefer sudo docker ... or rootless Docker for safer isolation.
• Consider rootless Docker if you want to reduce risk.

11) Troubleshooting: still getting permission denied?

If you followed Option A and it still fails, walk through these steps.

11.1 Did you log out and log back in?

This is the #1 reason the fix “didn’t work”.

Run:

groups

If you still don’t see docker, your session hasn’t picked up the new group membership. Log out completely (end the session) and log in again, or use:

newgrp docker

11.2 Is the socket group actually docker?

Check:

ls -l /var/run/docker.sock

If the group is not docker, then adding yourself to docker won’t help.

You can also check the daemon configuration and service:

ps aux | grep dockerd | grep -v grep
systemctl cat docker

11.3 Is Docker running?

sudo systemctl status docker --no-pager

If it’s failed, view logs:

sudo journalctl -u docker --no-pager -n 200

Fix the daemon issue first; permission changes won’t help if the daemon is down.

11.4 Are you on a system without systemd?

Some environments (older distros, minimal containers, WSL setups) may not use systemctl. In that case:

• Check if dockerd is running:

ps aux | grep dockerd

• Start Docker depending on your init system (varies widely). On SysVinit-based systems, you might use:

sudo service docker start

11.5 Are you connecting to a different socket?

Check:

docker context ls
docker context show
echo "$DOCKER_HOST"

If your context points to a different endpoint, switch back:

docker context use default

Then retry:

docker ps

11.6 Advanced: group ID mismatch (rare, but possible)

In unusual cases (especially with NFS home directories, LDAP users, containers, or custom setups), the docker group ID may not match what you expect.

Check numeric IDs:

getent group docker
stat -c '%U %G %a %n' /var/run/docker.sock

If the socket group is docker but your user still can’t access it, confirm your user is truly in that group:

id

Summary: choose the right fix

• Best beginner fix on Linux: add your user to the docker group

  sudo usermod -aG docker "$USER"
  # then log out/in

• Quick workaround: use sudo docker ...
• More secure approach: rootless Docker
• Avoid: chmod 666 /var/run/docker.sock (too permissive)

Appendix: Command reference (copy/paste)

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

# Check your groups
groups
id -nG "$USER"

# Add user to docker group
sudo groupadd docker
sudo usermod -aG docker "$USER"

# Apply group changes (alternative to logout/login)
newgrp docker

# Start/enable docker daemon (systemd)
sudo systemctl start docker
sudo systemctl enable docker
sudo systemctl status docker

# Test docker
docker info
docker ps
docker run --rm hello-world

If you share the exact error message and the output of these two commands:

ls -l /var/run/docker.sock
id

…I can tell you precisely which cause applies and which fix is safest for your setup.