If you’ve encountered the dreaded Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock error, you’re definitely not alone. This is one of the most common stumbling blocks for developers working with Docker, and frankly, it can be pretty frustrating when you just want to run a simple container.
Having worked with Docker across various Linux distributions and development environments, I’ve seen this error pop up countless times—whether it’s on a fresh Ubuntu installation, a CentOS server, or even within WSL2 on Windows. The good news? It’s completely fixable, and once you understand what’s happening behind the scenes, you’ll know exactly how to prevent it in the future.
1. Understanding the Docker Permission Denied Error
Before we jump into solutions, it’s crucial to understand what’s actually happening when this error occurs. Docker daemon communicates through a Unix socket located at /var/run/docker.sock, and by default, this socket is owned by the root user and the docker group.
When you see this error message:
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http:///var/run/docker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied
What’s essentially happening is that your user account doesn’t have the appropriate access rights to the Docker daemon socket. The Docker daemon always runs as the root user for security reasons, and regular user accounts need special permissions to communicate with it.
You can verify the current permissions by running:
ls -l /var/run/docker.sock
You’ll typically see something like:
srw-rw---- 1 root docker 0 Mar 13 06:05 /var/run/docker.sock
This shows that only the root user and members of the docker group have read and write access to the socket.
2. Quick Temporary Solution: Using Sudo
The fastest way to bypass this error is to run your Docker commands with sudo:
sudo docker ps
sudo docker run hello-world
sudo docker build -t myapp .
Running the command with sudo to acquire root privileges usually resolves the issue. However, this is far from ideal for regular development work. Having to type your password constantly gets old quickly, and it’s not a scalable solution for automated scripts or CI/CD pipelines.
While this approach works, I strongly recommend implementing one of the permanent solutions below for a better development experience.
3. The Recommended Permanent Solution: Adding User to Docker Group
This is the gold standard solution that 90% of the time, is all you need. Here’s how to do it properly:
Step 1: Create the Docker Group (if it doesn’t exist)
First, check if the docker group exists and create it if necessary:
sudo groupadd docker
If it exists, you’ll see “group already exists”—no harm done. If not, it’s created.
Step 2: Add Your User to the Docker Group
Add your current user to the docker group:
sudo usermod -aG docker $USER
The -aG option appends docker to your user’s groups; $USER is your current username. You can also specify your username explicitly:
sudo usermod -aG docker yourusername
Step 3: Apply the Group Changes
Here’s the critical step that many people miss: group changes don’t kick in until you refresh your session. You have several options:
Option A: Log out and log back in (Recommended)
- Exit your terminal completely
- Log out of your desktop session
- Log back in
Option B: Use newgrp command
newgrp docker
Option C: Start a new shell session
su - $USER
Step 4: Verify the Solution
Test that everything works:
docker run hello-world
docker ps
Success means it lists running containers (or an empty list) without errors.
You can also verify your group membership:
groups
You should see docker in the list of groups.
4. Alternative Solutions for Specific Scenarios
Solution for WSL2 Users
If you’re using Windows Subsystem for Linux (WSL2), you might need an additional step:
sudo service docker start
WSL Users: On Windows Subsystem for Linux, run sudo service docker start if systemctl fails.
Docker Desktop Users
For Docker Desktop on Windows or Mac, this permission issue typically doesn’t occur since Docker Desktop handles the daemon differently. However, if you’re running Docker CE in WSL2 alongside Docker Desktop, conflicts can arise.
Restart Docker Service
Sometimes restarting Docker may be sufficient to stop the error from appearing:
sudo systemctl restart docker
Check if the service is running properly:
sudo systemctl status docker
Look for Active: active (running) in the output.
5. Security Considerations and What NOT to Do
Avoid Dangerous Permission Changes
You might come across suggestions to run:
sudo chmod 666 /var/run/docker.sock
Don’t do this! This opens up the Docker socket to everybody and defeats any system security that may be in place. It’s strongly discouraged on production systems or shared environments.
Why the Docker Group Method is Secure
The docker group grants root-level privileges to the user, but it’s a controlled way to grant these privileges. Members of the docker group can effectively gain root access through Docker, but this is intentional and manageable through proper user management.
For environments requiring higher security, consider using Docker’s rootless mode, which allows running the Docker daemon and containers as a non-root user.
6. Troubleshooting Common Issues
Problem: Still Getting Permission Denied After Adding to Group
Solution: Make sure you’ve logged out and back in completely. On some systems, you might need to restart the machine entirely.
Problem: Docker Group Doesn’t Have Proper Socket Access
Check the socket ownership:
ls -l /var/run/docker.sock
If it shows root root instead of root docker, fix it with:
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock
Problem: Docker Service Not Running
Ensure Docker is running:
sudo systemctl start docker
sudo systemctl enable docker
Problem: ~/.docker Directory Permission Issues
If you initially ran Docker CLI commands using sudo before adding your user to the docker group, you may see errors related to the ~/.docker/ directory being created with incorrect permissions.
Fix this with:
sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R
7. Best Practices for Docker Permission Management
For Development Environments
- Always add your user to the docker group after installation
- Verify group membership with the
groupscommand - Test with a simple
docker run hello-worldcommand
For Production Environments
- Consider using Docker’s rootless mode for enhanced security
- Implement proper user management and access controls
- Regular audits of docker group membership
For Team Environments
- Document the setup process for new team members
- Consider using configuration management tools (Ansible, etc.) to standardize setup
- Implement proper backup procedures for Docker configurations
8. Modern Docker Updates and Compatibility
In 2025, with Docker 25.x rolling out (latest stable as of March), these issues still pop up—especially on fresh installs or after system updates. The solutions provided in this guide remain valid across:
- Ubuntu 20.04, 22.04, and newer versions
- CentOS 7, 8, and Rocky Linux
- Debian 10, 11, and 12
- Windows WSL2 environments
- Docker Desktop 4.28 and CLI updates in 2025
9. Quick Reference Command Summary
Here’s a handy reference for the complete solution:
# Create docker group (if needed)
sudo groupadd docker
# Add user to docker group
sudo usermod -aG docker $USER
# Restart Docker service
sudo systemctl restart docker
# Log out and log back in, then test
docker run hello-world
For troubleshooting:
# Check socket permissions
ls -l /var/run/docker.sock
# Check group membership
groups
# Check Docker service status
sudo systemctl status docker
# Fix .docker directory permissions (if needed)
sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
The “permission denied while trying to connect to the Docker daemon socket” error might seem intimidating at first, but it’s actually a straightforward permissions issue with well-established solutions. By adding your user to the docker group, fixing /var/run/docker.sock, and restarting the daemon, you’ll be back to container bliss in no time.
The key takeaways are:
- Understand the root cause: It’s about Unix socket permissions, not Docker installation issues
- Use the proper solution: Add your user to the docker group rather than using chmod hacks
- Remember to refresh your session: Group changes require logging out and back in
- Think about security: The docker group grants significant privileges, so manage membership carefully
With these solutions in your toolkit, you’ll be able to run Docker commands smoothly without the constant need for sudo, making your development workflow much more efficient. Whether you’re building applications, managing containers, or working with complex multi-container setups, proper permission management is the foundation for a smooth Docker experience. 🙂