How to Fix “Permission Denied” When Running Docker Without Sudo

How to Fix “Permission Denied” When Running Docker Without Sudo
Photo by iso topon / Unsplash

If you’ve ever tried running a simple docker ps command and been greeted with a “permission denied while trying to connect to the Docker daemon socket” error, you’re not alone. This issue is one of the most common frustrations for developers who are new to Docker or managing multi-user environments on Linux.

Let’s walk through why this happens, how to fix it properly, and what security and operational considerations you should keep in mind.


🔍 Understanding the Root Cause

Docker runs as a daemon (background service) on Linux systems. This daemon (dockerd) listens on a Unix socket located at /var/run/docker.sock.
By default, this socket file is owned by root and accessible only by users in the docker group.

When you execute:

docker ps

your shell attempts to communicate with the Docker daemon through that socket.
If your current user is not part of the docker group, the kernel prevents access — resulting in the familiar “permission denied” error.

Using sudo docker ps works because sudo elevates privileges to root, bypassing the socket’s restrictions.


🧩 The Correct Way to Fix It

Instead of running Docker commands as root (which is risky), you should give your regular user the proper permissions.

Step 1 — Add your user to the Docker group

sudo usermod -aG docker $USER

This command appends (-a) your user to the group (-G docker) without removing existing group memberships.

Step 2 — Apply the new group membership

You can either log out and log back in, or apply it immediately using:

newgrp docker

Step 3 — Confirm your membership

groups

You should now see docker listed among your groups.

Step 4 — Test Docker access

Run:

docker ps

If everything is configured correctly, it will list your running containers without needing sudo.


⚙️ Verifying the Docker Socket Permissions

It’s always a good idea to confirm that the Docker socket itself is properly configured.
Run:

ls -l /var/run/docker.sock

You should see something like this:

srw-rw---- 1 root docker 0 Oct 16 22:00 /var/run/docker.sock

Here, the socket is owned by root, but readable and writable by the docker group — exactly what we want.

If the group ownership isn’t correct, fix it with:

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

🔒 Security Considerations

While adding your user to the Docker group is the standard fix, it comes with serious security implications that many overlook.

  • Members of the docker group have root-equivalent privileges.
    Docker allows mounting the host filesystem or executing commands as root inside containers. A malicious user with Docker access could easily gain full system control.
  • Limit group membership.
    Only trusted users (typically developers or admins) should belong to the Docker group.
  • Consider socket-based authorization plugins.
    Tools like Docker Socket Proxy can help restrict or audit API access.
  • Avoid exposing /var/run/docker.sock to containers directly unless you fully understand the risks. It effectively gives containers full control over the host Docker daemon.

🧠 Additional Best Practices

  1. Automate permissions setup for new users
    You can include the usermod -aG docker step in onboarding scripts or server provisioning tools (like Ansible or Terraform).
  2. Use sudo systemctl enable docker to ensure the Docker daemon starts automatically on boot.
  3. Regularly check group memberships
    Run grep docker /etc/group to verify who currently has Docker privileges.
  4. For CI/CD environments, use dedicated service accounts with limited scope instead of general user accounts.
  5. Monitor the socket file’s integrity
    In hardened systems, security tools can watch /var/run/docker.sock for unexpected permission changes.

🧭 Troubleshooting Tips

If the error persists after adding your user to the group:

  • Ensure you’ve logged out and back in (or used newgrp docker).
  • Check for multiple Docker installations (e.g., from Snap and from apt), as they can conflict.

Confirm the socket path (/var/run/docker.sock) matches what your Docker CLI expects:

docker info

Verify that Docker is actually running:

sudo systemctl status docker

✅ Finally

This issue isn’t a bug — it’s a deliberate Linux security mechanism.
The safest and most practical way to fix it is to join the docker group, understand the implications, and enforce good operational hygiene.

By following these steps, you’ll be able to run Docker commands confidently without sudo, while maintaining a secure and well-managed development environment.


In summary:

Add your user to the docker group, verify the socket permissions, and stay mindful of the security implications. Docker is powerful — and with great power comes great responsibility. 🧑‍💻

Support Us

Share to Friends