Permission Denied While Trying to Connect to the Docker Daemon Socket.

In this article, you’ll learn why Docker socket permissions fail, how to repair runner access, and what privilege you grant when you do. That distinction matters because cloud failures usually emerge at the seams between configuration, identity, networking, and operations.

Out of the blue today, my first day back after Christmas break, I got this when running a GH Actions Workflow on one of our Self-Hosted Linux Runners 😱:

It had been running fine prior to my break so what gives? I started to investigate…

I logged in to the Linux VM where this particular Self-Hosted Runner is hosted with the same credentials as used when I installed the Self-Hosted Runner originally. I used the following command to confirm the same outcome:

docker ps

Yup, same thing.

The next configuration I wanted to check was whether this user is a member of the docker group so I used this command:

sudo groups <user>

Mmmmm, that’s odd. This user wasn’t a member and therefore begs the question, how did this ever work in the first place?!!

I added this user using this command:

sudo usermod -a -G docker <user>

I ran docker ps again but still no dice. 🤔.

I then checked the status of the docker service using this command:

sudo systemctl status docker

It reported:

Ok, what next? 🤔

I decided to restart the self-hosted service so I entered these commands:

cd actions-runner
sudo ./svc.sh start

This is when I saw these failures:

I restarted the Self-Hosted Runner using these commands:

sudo ./svc.sh stop
sudo ./svc.sh start

Then I logged out and back in again to confirm docker access docker ps and finished off by re-running the failed GH Action Workflow. 🥳 Equilibrium is once again restored. As per protocol, I shared issue and resolution with our IT Team in case this crops up again when I’m not online to help.

2026 technical review

Technical review: the permission is the security boundary

Adding a user to the docker group commonly resolves access to the rootful Docker socket, but Docker documents that membership as granting root-level privileges. On a shared or self-hosted CI machine, that is not a routine convenience; workflow code can mount the host filesystem or start privileged containers.

First confirm which socket and context the CLI is using, inspect ownership, and check whether the daemon is running. If group access is appropriate, provision it deliberately and start a new login session so group membership is refreshed. Do not make the socket world-writable.

For stronger isolation, evaluate Docker rootless mode or ephemeral runners that are destroyed after a job. Restrict which repositories can target a privileged runner, avoid untrusted pull-request code, and rotate any credentials that may have been exposed on a previously shared host.

References

• Docker Engine documentation
• Docker rootless mode

Closing thought

Removing a Docker socket permission error is easy; understanding that the new permission is effectively authority over the host is the part that deserves care.