mirror of
https://github.com/nektos/act.git
synced 2026-04-26 17:35:49 +03:00
[GH-ISSUE #1744] Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? on Ubuntu while docker commands are working #855
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#855
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kintel on GitHub (Apr 19, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/1744
Bug report info
Command used with act
Describe issue
Error: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied
Link to GitHub repository
No response
Workflow content
Relevant log output
Additional information
No response
@catthehacker commented on GitHub (Apr 19, 2023):
dial unix /var/run/docker.sock: connect: permission deniedyou don't have permissions to access the socket@kintel commented on GitHub (Apr 19, 2023):
That doesn't seem to be the problem:
@dataheadless commented on GitHub (May 8, 2023):
You can check answers here as well
Cannot connect to the docker daemon at linux
@kintel commented on GitHub (May 9, 2023):
@dataheadless The docker daemon runs, and can be talked to from Linux without problems (see above). Yet, when running nektos, it fails to connect to the daemon.
@andrew-pickin-epi commented on GitHub (May 11, 2023):
There are solutions posted here and elsewhere which may fix this issue for a while (but are unlikely to survive a reboot).
chown 1001 /var/run/docker.sockchmod a+rw /var/run/docker.sockNeither of these are ideal, as you are changing what the system has defined the ownership/permissions to be (and it requires sudo/root which some folk might not have). Slightly better might be
setfacl -m runner:rw /var/run/docker.sockNormally one would add the user to the
dockergroup but the problem we have here is there is no guarantee that the gid for the docker group inside the container matches that of the host. If we were invoking the container ourselves the--group-addcould pass in the host's docker group gid. There is a feature request https://github.com/nektos/act/issues/1798.In the meantime we can create a bespoke image with the appropriate group added (change name/version to suit).
Create a
Dockerfile:Build the image:
Use this image in
act:A bit long-winded, but you only have to do it once (for each version), it doesn't require sudo/root or changing the system permissions and will survive a reboot. YMMV.
@giosava94 commented on GitHub (Nov 6, 2023):
Hi,
I'm having the same issue. Any news about this topic?
I also used the command
act --pull=false, but it said it is unable to determine if the image exists because it can't access to docker daemon socket.Error: unable to determine if image already exists for image 'catthehacker/ubuntu:act-latest' (): permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/catthehacker/ubuntu:act-latest/json": dial unix /var/run/docker.sock: connect: permission denied@jonancm commented on GitHub (Jan 1, 2024):
I have a similar issue on Fedora 39 using Podman (using the official packages
podman&podman-docker) andactinstalled as an extension for the GitHub CLI (official packagegh):Problems with this setup (Fedora 39 + Podman)
After some digging, I've identified several issues:
/var/run/docker.sockis a broken link to/run/podman/podman.sock. The file/run/podman/podman.sockdoesn't exist because by default Podman works in daemonless mode, so there's no daemon and therefore no socket. For the file/run/podman/podman.sockto exist, I've had to start/enable the systemd service for Podman (on Fedora:podman.socket&podman.service)./var/run/docker.sock, but not for/run/podman/podman.sock. To solve this, I've decided to enable the systemd service as an unprivileged user rather than as root, and set the environment variableDOCKER_HOSTto point to/run/user/$EUID/podman/podman.sock.actseems to use theDOCKER_HOSTenvironment variable for some steps of the process, but not all of them. When I setDOCKER_HOST=unix:///run/user/$EUID/podman/podman.sock, pulling the Docker image works, but creating the container still fails. In the end, I've decided to overwrite the symbolic link at/var/run/docker.sockto point to/run/user/$EUID/podman/podman.sock.How to diagnose the root cause
Here are the steps I've used to find out the root cause:
Check that the socket files exist and have the right permissions:
Create the socket if it doesn't exist:
Check that your user can read the sockets:
Enable the socket/service as an unprivileged user instead of root:
Verify again using the user socket:
Overwrite the symbolic link at
/var/run/docker.sockifact/podmanis still trying to access/var/run/docker.sockinstead of using theDOCKER_HOSTenvironment variable:and check again:
Solution for Fedora 39 + Podman
In the end, these are the commands that I've used to fix the problem on Fedora 39 using Podman:
Notice that this is an acceptable workaround for me, since I'm the only user who uses
act&podmanon my computer, but it may not work if multiple unprivileged users need to useact&podmanon the same computer, because the user socket only has permissions for that specific user.@mmv08 commented on GitHub (Mar 6, 2024):
I had a similar issue with Docker Desktop on Ubuntu; in my case, the problem was the missing
/var/run/docker.sock. I fixed it by creating a symlink to the sock file in the docker desktop folder.The solution is taken from this thread on the docker forum: https://forums.docker.com/t/is-a-missing-docker-sock-file-a-bug/134351
@github-actions[bot] commented on GitHub (Sep 3, 2024):
Issue is stale and will be closed in 14 days unless there is new activity