Docker Permission Denied? Fix the Socket Error Step by Step

If you see permission denied when you run docker on Linux, your user can't open the Docker daemon's Unix socket. Add your user to the docker group, log out and back in, and run docker run hello-world to confirm. That fixes most cases on Ubuntu and other distributions.

The group has a catch: membership grants root-level privileges. If that bothers you, use rootless mode instead, or the on-demand newgrp shell described below. Both are covered here, along with the other "permission denied" errors people hit with Docker.

The error and why it happens#

The usual message looks like this:

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

The Docker daemon binds to a Unix socket, not a TCP port. By default the root user owns that socket, and other users can only reach it with sudo. When the daemon starts, it creates the socket so that members of the docker group can access it. Your user isn't in that group yet, so the kernel says no.

The daemon itself always runs as root. Your docker command is only a client talking to it through the socket, so the fix is about who is allowed to talk to that socket.

On some distributions the package manager creates the docker group when it installs Docker Engine. In that case you don't need to create it yourself.

Fix 1: add your user to the docker group#

This is the most common fix. Before you run it, read the warning in the next paragraph.

Warning: the docker group grants root-level privileges to the user. Anyone in it can effectively act as root on that machine. On a personal dev box that's usually an accepted tradeoff. On a shared or production server, think twice. The Docker Daemon Attack Surface page explains the impact.

Create the group (this does nothing harmful if it already exists, but will print an error), then add yourself:

sudo groupadd docker
sudo usermod -aG docker $USER

The -aG flags append the group. Without -a you'd replace your other supplementary groups, so keep both letters.

Now make the new membership take effect. Log out and log back in so your group membership is re-evaluated. If you're running Linux in a virtual machine, you may need to restart the VM. For a quick test in the current terminal, you can run this instead:

newgrp docker

Confirm it worked:

docker run hello-world

This downloads a test image and runs it in a container. The container prints a message and exits. If you see that message without sudo, you're done.

Check your groups#

If it still fails, check whether your current session actually has the group. Run id -nG and look for docker in the list. Group membership stays in the credentials of processes that already exist, so a terminal opened before you ran usermod won't see the change.

This small script does the same check on sample output, so you can see the logic:

const sample = [
  'user wheel',
  'user wheel docker',
];

for (const line of sample) {
  const groups = line.trim().split(/\s+/);
  const ok = groups.includes('docker');
  console.log(`${line.padEnd(20)} -> ${ok ? 'can use the socket' : 'permission denied'}`);
}

On your machine, replace the sample with the real output of id -nG.

Fix 2: use a Docker-enabled shell on demand#

Permanent membership means every process in your login session can reach the Docker socket. If you'd rather not have that, keep your user out of the group and enter it only when needed. The Docker docs describe this as accessing the docker group on demand, using a group password.

The setup, in order:

# make sure the group exists
sudo groupadd --force docker

# if you were a member, remove yourself
sudo gpasswd --delete "$USER" docker

Then sign out of the desktop or SSH session completely and sign back in. Opening a new terminal isn't enough. Check that id -nG no longer lists docker. Next, set a dedicated password for the group:

sudo gpasswd docker

Don't add your user back to the group. Users configured as group members can use newgrp without entering the group password. When you need Docker, start a child shell:

newgrp docker

In that shell, id -un still shows your username and id -gn shows docker. Run docker run --rm hello-world to confirm, then exit when you're done.

This method has real limits, and the docs say so plainly:

• A group password reduces ambient access, but it doesn't reduce the root-level privileges once access is granted.
• It isn't a security boundary against malicious code running as your user. That code can modify shell configuration or scripts you later use from the Docker-enabled shell.
• Files you create in that shell normally have docker as their group owner. Use it only for Docker commands.
• Exiting the shell doesn't revoke access from background or daemonized processes started inside it.

To turn the password setup off later, run sudo gpasswd --restrict docker. Afterward only configured group members can enter the group. It doesn't terminate shells that are already open.

Fix 3: run Docker rootless#

If you want Docker without root privileges at all, use rootless mode, where the daemon runs as your user instead of root. The Docker docs point to it as the option for running Docker without root, and for stronger isolation they recommend it (or a virtual machine) over group tricks. I'd choose it on any machine where the docker group's root-equivalent access makes you uneasy.

The setup has distribution-specific prerequisites, so follow the official rootless mode guide rather than a copy-pasted snippet from a forum.

Permission denied on ~/.docker/config.json#

There's a second error that looks similar but has a different cause. If you ran Docker CLI commands with sudo before adding yourself to the group, you may see:

WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied

This means the permissions on your ~/.docker/ directory are wrong, because sudo created or touched it as root. You have two options. Remove the directory, which gets recreated automatically but loses any custom settings, or fix its ownership:

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R

The -R flags apply recursively, so check the path before pressing Enter. To confirm, run any docker command and check that the warning is gone.

Permission denied on a mounted volume or with os error 13#

The Docker docs in my source pack don't cover bind-mount permissions, so I'll keep this short and general. An error such as permission denied (os error 13) means a process tried to open a file or directory it has no right to. That's a plain Linux ownership problem, not a socket problem.

To narrow it down:

1. Decide which side is failing. If the docker command itself fails, you're back at the socket. If the error comes from inside a running container, it's file ownership.
2. Compare numeric IDs on the host with ls -ln on the mounted path and id for the user the process runs as. The numbers matter, not the names.
3. Fix ownership or permissions on the host directory to match the user that needs to write there.

Avoid fixing it with a recursive wide-open permission change on a directory you don't fully understand.

Common mistakes and what not to do#

• Prefixing everything with sudo. It works, but it's how ~/.docker ends up owned by root and produces the config warning above. It also keeps you on the root path for every command.
• Forgetting to log out. usermod changes the group database, not your running shell. Log out and in, restart the VM if you're in one, or use newgrp docker for a quick test.
• Running usermod -G without -a. That replaces your supplementary groups instead of appending.
• Treating the group as harmless. It's root-level access. Don't add service accounts or shared users to it casually.
• Loosening permissions on the socket itself. The daemon sets up the socket for the docker group on purpose. Making it open to everyone gives every local user and process root-equivalent access, so I'd never do it.
• Adding yourself back after setting a group password. Members skip the password prompt, which defeats the point.

Quick reference#

Checklist:

• [ ] docker group exists (sudo groupadd docker)
• [ ] You're a member (sudo usermod -aG docker $USER)
• [ ] You logged out and back in, or restarted the VM
• [ ] id -nG lists docker
• [ ] docker run hello-world works without sudo
• [ ] You've decided whether root-level access fits this machine, and considered rootless mode if not

The full official procedure is in the Linux post-installation steps.

Quick answers