To add your user to the Docker group on Linux, run sudo usermod -aG docker $USER and refresh your session. This fixes the permission denied while trying to connect to the Docker daemon socket error permanently by giving your account direct access to the Docker socket at /var/run/docker.sock.
Why the Error Happens
The Docker daemon listens on a Unix socket rather than a network port. By default that socket is owned by root and readable only by members of the docker group. A regular user account that does not belong to that group gets blocked every time it tries to talk to the daemon. Running sudo docker works because it executes the command as root, but that is not a sustainable habit.
You can confirm this by checking the socket permissions:
ls -l /var/run/docker.sock
The output will show root as owner and docker as a group. Your regular user is neither, so access is denied. If you have not yet installed Docker, see How to Install Docker on Linux first.
Step 1: Confirm the Docker Group Exists
Docker’s official installer creates the docker group automatically on most distributions. Verify it is there:
sudo cat /etc/group | grep docker
If nothing appears, create the group manually:
sudo groupadd docker
Step 2: Add Your User to the Group
sudo usermod -aG docker $USER
The -a flag appends your user to the new group without removing them from any existing groups. Omitting -a would replace all your supplementary group memberships with just docker, which would break other things.
Replace $USER with a specific username if you are adding someone other than yourself.
Step 3: Refresh Your Session
Your current terminal session was started before the group change and does not know about it yet. For a quick fix in the current terminal:
newgrp docker
For a permanent fix that applies to every new session, log out of your desktop environment or close your SSH session and log back in. On a virtual machine, a full reboot is the most reliable option.
Step 4: Verify It Worked
Check that docker appears in your group list:
groups
Then run a test container without sudo:
docker run hello-world
A successful output means the permission issue is resolved. If this is your first time running a container, How to Run Your First Docker Container walks through what the hello-world output means.
If You Still Get Permission Errors
If the error persists after refreshing your session, the most common cause is a ~/.docker/ directory previously created by sudo docker. That directory is owned by root and blocks access for your regular user. Fix it:
sudo chown "$USER":"$USER" "$HOME/.docker" -R
If the daemon itself seems unresponsive, restart it and re-check the socket ownership:
sudo systemctl restart docker
ls -l /var/run/docker.sock
The socket should show root as owner and docker as group. If it shows anything else, restarting Docker resets it to the correct state. Never run chmod 666 on the socket that makes it writable by every user on the system, which is a serious security hole.
The Security Implication Worth Knowing
Membership in the docker group is effectively equivalent to root access on the host. A user in the group can mount any host directory into a container and read or modify it, including /etc, /root, and anything else on the filesystem. This is not a theoretical risk; it takes one command.
On a personal machine where you already have sudo access, this does not meaningfully change your risk profile. On a shared development server or a production machine, it does. Only add users you fully trust to the docker group on shared systems. For environments where that level of access is not acceptable, Docker’s rootless mode runs the daemon entirely within a user namespace and eliminates this exposure. The official Docker rootless mode documentation covers the setup.
The Takeaway
Adding your user to the docker group with sudo usermod -aG docker $USER fixes the permission denied error by giving your account access to the Docker socket. The change does not take effect until you refresh your session with newgrp docker or log out and back in. On shared or production systems, treat group membership carefully, as it carries the same access as root on the host.
