Meta description: I ran into “permission denied” errors with Docker on Ubuntu more times than I’d like to admit — here’s exactly how I fixed them for good.
Last updated: July 8, 2026
The first time I hit Got permission denied while trying to connect to the Docker daemon socket I was mid-deploy, staring at a terminal that refused to cooperate. I’d just installed Docker on a fresh Ubuntu server and assumed sudo apt install docker.io was the end of the story. It wasn’t. If you’re stuck on this exact error right now, I’ve been there, and this is the fix that actually sticks.
TL;DR
- The root cause is almost always that your user isn’t part of the
dockergroup, so it can’t talk to the Docker daemon socket. - Adding your user to the
dockergroup and refreshing your session fixes it in under two minutes. - If the error persists after that, it’s usually a socket permissions issue or a leftover
sudo-created config file.
Background: Why This Happens
Docker runs as a background daemon (dockerd) that listens on a Unix socket at /var/run/docker.sock. By default, that socket is owned by root and the docker group — not by your regular user. Every docker command you run without sudo needs permission to talk to that socket, and if your user isn’t in the right group, the kernel simply denies it.
This is a deliberate security decision, not a bug. Docker permission denied errors exist because being able to talk to the Docker daemon is functionally equivalent to root access on the host — anyone in the docker group can mount the host filesystem into a container and read or write anything.
[SOURCE: https://docs.docker.com/engine/install/linux-postinstall/]
Prerequisites
- Ubuntu 20.04, 22.04, or 24.04 (I’ve tested this fix on all three)
- Docker Engine already installed (
docker --versionshould return something) - A regular (non-root) user account you use for day-to-day work
Step-by-Step Fix
1. Confirm the exact error
Run a basic Docker command without sudo to reproduce the issue:
docker ps
You’ll see something 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.43/containers/json": dial unix /var/run/docker.sock: connect: permission denied
2. Create the docker group (if it doesn’t exist)
On most installs this group is created automatically, but it’s worth confirming:
sudo groupadd docker
If the group already exists, this command just tells you so — it’s safe to run either way.
3. Add your user to the docker group
sudo usermod -aG docker $USER
The -aG flags matter here: -a appends the group instead of replacing all existing groups, and -G specifies the group list. Skipping -a is a mistake I made once, and it silently removed my user from every other group I was in.
4. Apply the new group membership
Group changes don’t take effect in your current shell session automatically. You have two options:
newgrp docker
This starts a new shell with the updated group applied immediately. Alternatively, log out and back in, or reboot if you’re on a desktop environment.
5. Verify the fix
docker ps
If you see an empty container list (or your running containers) with no error, you’re done.
Pro Tip: Run
groups $USERafter step 3 to double-checkdockershows up in the output before you assume the fix worked. It’s a five-second sanity check that saves a confusing debugging loop later.
[INTERNAL LINK: related article]
Real-World Tips I Use in Production
On CI runners and staging boxes, I never rely on interactive newgrp — it doesn’t persist across non-interactive SSH sessions or automation scripts. Instead, I bake the usermod -aG docker command into my provisioning scripts (Ansible, cloud-init, or Terraform user_data) and just accept that the very first deploy after provisioning needs a fresh session.
I also avoid running Docker commands with sudo as a long-term workaround, even though it “fixes” the permission error immediately. Mixing sudo docker and plain docker in the same project creates files owned by root inside bind-mounted volumes, which then breaks permissions for your regular user later.
Common Errors and How I Fixed Them
Error: permission denied even after adding user to docker group This usually means the session wasn’t refreshed. I once spent 20 minutes convinced my fix was broken before realizing I’d forgotten to close and reopen my SSH session.
Error: /var/run/docker.sock: no such file or directory This means the Docker daemon itself isn’t running. I fixed this with sudo systemctl start docker and sudo systemctl enable docker so it survives reboots.
Error: permission denied on docker-compose but not docker I hit this on an older docker-compose v1 binary that had its own socket-handling quirks. Upgrading to the Docker Compose v2 plugin (docker compose, no hyphen) resolved it completely.
Security Note: Being in the
dockergroup is root-equivalent access to the host. Don’t add shared or low-trust accounts to this group just to silence a permissions error — that’s a real attack surface, not a shortcut.
[SOURCE: https://github.com/moby/moby/issues/9584]
FAQ
Q: Why do I get permission denied on Docker even though I used sudo? A: If sudo docker ps works but docker ps doesn’t, your user simply isn’t in the docker group yet — follow the usermod -aG docker $USER step above.
Q: Do I need to reboot after adding my user to the docker group on Ubuntu? A: No, newgrp docker or a fresh login session is enough; a full reboot is only needed on some desktop environments where session group refresh doesn’t happen otherwise.
Q: Why does docker permission denied still happen after usermod on WSL2? A: WSL2 often requires restarting the WSL instance itself with wsl --shutdown from PowerShell, not just a new terminal tab, for group changes to apply.
Q: Is it safe to just always use sudo with docker commands? A: It works, but it creates root-owned files in mounted volumes and isn’t a real fix — it’s better to resolve the group membership properly.
Q: How do I check which users are in the docker group on Ubuntu? A: Run getent group docker to see every user currently assigned to that group.
Conclusion
Docker’s permission model exists for a good security reason, but it trips up almost everyone the first time they install it. Once you understand it’s a group membership issue and not something broken in your install, the fix takes under two minutes.
About the Author
I’m a backend developer with over 8 years of experience building and deploying containerized applications on Linux servers, primarily working with Docker, Kubernetes, and CI/CD pipelines. I’ve managed production Docker environments across bare-metal Ubuntu servers, AWS EC2, and WSL2 development setups. I write about the exact errors I hit in real projects, not just theoretical fixes.