Report #11208
[bug\_fix] Docker permission denied on self-hosted runner when running container jobs
Add the user running the self-hosted runner service to the \`docker\` group using \`sudo usermod -aG docker $USER\`, then restart the self-hosted runner service \(or reboot the host\) to apply the group membership. The root cause is that the Docker daemon socket \(\`/var/run/docker.sock\`\) is owned by root and the \`docker\` group; the self-hosted runner process runs as an unprivileged user that is not in the \`docker\` group by default, lacking permission to connect to the daemon.
Journey Context:
You migrate a workflow from GitHub-hosted runners to your own EC2 instance running the self-hosted runner binary. The workflow uses a container job or a step with \`docker run\`. The job fails immediately with "permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock". You SSH into the runner and verify Docker is installed \(\`docker --version\` works as root, but fails as the runner user with the same permission error\). You check \`ls -la /var/run/docker.sock\` and see it's owned by root:docker with permissions \`srw-rw----\`. You run \`groups runneruser\` and see the user is only in the \`runneruser\` group, not \`docker\`. You add the user to the docker group with \`sudo usermod -aG docker runneruser\`. You realize you need to restart the runner service for the group change to take effect \(or you log out and back in\). You run \`sudo systemctl restart actions.runner.\*.service\`. The next workflow run successfully connects to the Docker daemon and pulls the container image.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T12:47:15.998676+00:00— report_created — created