How to Fix Docker Permission Denied on Ubuntu

You install Docker on Ubuntu, run your first command, and get slapped with this:

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

Docker is installed and the daemon is running. The problem is that your regular user account isn’t allowed to talk to it. This is expected on a fresh install, not a broken setup, and the fix takes about a minute plus one log-out.

This guide explains why the error happens, the supported way to fix it, why the fix doesn’t seem to work right away, and the security trade-off you should understand before you apply it to a shared server.

Why this happens#

The Docker daemon (dockerd) runs as root and listens on a Unix socket at /var/run/docker.sock. That socket is owned by root and the docker group. Check it yourself:

ls -l /var/run/docker.sock

srw-rw---- 1 root docker 0 Sep 19 09:14 /var/run/docker.sock

The permissions are srw-rw----: root can read and write, members of the docker group can read and write, and everyone else gets nothing. A fresh user account isn’t in the docker group, so when you run docker ps it can’t open the socket and you get permission denied.

That’s also why sudo docker ps works — root always has access. Using sudo for every command is a workable stopgap, but it’s tedious and it’ll trip up scripts and tools that call docker directly.

The fix: add your user to the docker group#

This is the approach Docker documents in its Linux post-installation steps. Two commands, then refresh your session.

First, make sure the group exists. On most installs it already does, but this is harmless if it’s already there:

sudo groupadd docker

Then add your user to it. $USER expands to your current username:

sudo usermod -aG docker $USER

The -aG matters. -a means append to the user’s groups, and -G docker names the group. Leave out -a and you’d replace all of the user’s secondary groups with just docker, which can lock you out of sudo and other things. Always use -aG together.

Why it still says permission denied — and the real fix#

You run the usermod command, try docker ps again, and get the same error. Nothing’s broken. Group membership is loaded when your login session starts, so your current shell still has your old groups.

You have two ways to pick up the new membership:

# Option 1: apply the new group to your current shell immediately
newgrp docker

# Option 2 (cleaner): log out of the session entirely and log back in

newgrp docker starts a new shell with the docker group active, which fixes the current terminal right away. For a complete, consistent result — every terminal, your desktop session, anything you launch — log out and back in, or reboot. After that, confirm the group is really applied:

id -nG

You should see docker in the list. Now test Docker without sudo:

docker run --rm hello-world

If that pulls the image and prints the welcome message, you’re done. No more sudo, no more permission denied.

The security trade-off you should know#

Adding yourself to the docker group is convenient, but it’s not a small permission. Docker’s own security documentation is blunt about this: membership in the docker group is effectively equivalent to root access on the host.

The reason is simple. Anyone who can talk to the Docker socket can start a container that bind-mounts the host’s root filesystem and then read or modify anything on the machine:

# Illustration of why docker group = root. Don't run this on a box you care about.
docker run --rm -it -v /:/host alpine chroot /host

That command gives a shell with full access to the host’s files, no sudo required. So a user in the docker group can bypass normal permission boundaries entirely.

What this means in practice:

• Personal dev machine or a VM you own: adding your user to the docker group is a reasonable, common choice. The convenience is worth it and you already control the box.
• Shared server, a host with multiple admins, or anything production: be deliberate about who’s in the group. Each member effectively has root. Consider rootless Docker so the daemon and containers run as an unprivileged user, or restrict docker access through controlled sudo.

Why sudo isn’t a good long-term answer#

Running sudo docker for every command works, but it has rough edges that show up quickly:

• Tooling breaks. IDEs, build scripts, docker compose, and CI runners call docker directly and don’t prompt for a password. They’ll just fail with the same permission error.
• File ownership gets messy. Containers and bind mounts created under sudo end up owned by root, which causes confusing “permission denied” problems later when your normal user tries to read or edit those files.
• It trains a bad habit. Reaching for sudo reflexively is how people end up running things as root that didn’t need to be.

The docker group fixes all three because your user talks to the daemon directly, the way the tooling expects.

If it still doesn’t work#

A few things to check when the group is applied but Docker still refuses:

• The daemon isn’t running. Confirm with sudo systemctl status docker. If it’s stopped, sudo systemctl enable --now docker starts it and sets it to start on boot.
• You never actually logged out. Opening a new terminal tab in the same session may keep the old group set. A full log-out or reboot is the reliable test.
• You’re in a remote shell or container where group changes don’t propagate the way you expect. Reconnect after applying the change.

Once your user is in the docker group and your session has picked it up, the permission-denied error is gone for good on that machine. From here, the install Docker on Ubuntu Server guide covers a clean end-to-end setup if you want to confirm the rest of your install is solid.