catthehacker
commented
1 year ago dial unix /var/run/docker.sock: connect: permission denied you don't have permissions to access the socket
Open kintel opened 1 year ago
catthehacker
commented
1 year ago dial unix /var/run/docker.sock: connect: permission denied you don't have permissions to access the socket
kintel
commented
1 year ago That doesn't seem to be the problem:
$ curl --unix-socket /var/run/docker.sock http://localhost/version
{"Platform":{"Name":"Docker Engine - Community"},"Components":[{"Name":"Engine","Version":"23.0.2","Details":{"ApiVersion":"1.42", [...]
dataheadless
commented
1 year ago You can check answers here as well
kintel
commented
1 year ago @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
1 year ago 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.sock
Neither 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 besetfacl -m runner:rw /var/run/docker.sock Normally one would add the user to the docker group 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-add could 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:
ARG ACT_VERSION=act-20.04
FROM catthehacker/ubuntu:$ACT_VERSION as base
ARG DOCKER_GID=0
RUN sudo groupadd -g $DOCKER_GID host-docker && sudo usermod -aG host-docker runnerBuild the image:
docker build --build-arg DOCKER_GID=$(awk -F: '$1=="docker" {print $3}' /etc/group) --tag my/ubuntu:act-20.04 .
Use this image in act:
act -P ubuntu-20.04=my/ubuntu:act-20.04 --pull=falseA 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
9 months ago @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.
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
7 months ago I have a similar issue on Fedora 39 using Podman (using the official packages podman & podman-docker) and act installed as an extension for the GitHub CLI (official package gh):
$ gh act
[Continuous Integration/code-style ] 🐳 docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true
Error: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/create?fromImage=catthehacker%2Fubuntu&tag=act-latest": dial unix /var/run/docker.sock: connect: permission deniedAfter some digging, I've identified several issues:
/var/run/docker.sock is a broken link to /run/podman/podman.sock. The file /run/podman/podman.sock doesn'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.sock to 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 variable DOCKER_HOST to point to /run/user/$EUID/podman/podman.sock.act seems to use the DOCKER_HOST environment variable for some steps of the process, but not all of them. When I set DOCKER_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.sock to point to /run/user/$EUID/podman/podman.sock.Here are the steps I've used to find out the root cause:
Check that the socket files exist and have the right permissions:
sudo ls -l /var/run/docker.sock
sudo ls -l /run/podman/podman.sockCreate the socket if it doesn't exist:
sudo systemctl start podman.socket podman.serviceCheck that your user can read the sockets:
curl --unix-socket /var/run/docker.sock http://localhost/version
curl --unix-socket /run/podman/podman.sock http://localhost/versionEnable the socket/service as an unprivileged user instead of root:
sudo systemctl stop podman.socket podman.service
systemctl start --user --now podman.socket podman.serviceVerify again using the user socket:
curl --unix-socket /run/user/$EUID/podman/podman.sock http://localhost/version
DOCKER_HOST=unix:///run/user/$EUID/podman/podman.sock gh act -vOverwrite the symbolic link at /var/run/docker.sock if act/podman is still trying to access /var/run/docker.sock instead of using the DOCKER_HOST environment variable:
sudo ln -sf /run/user/$EUID/podman/podman.sock /var/run/docker.sockand check again:
curl --unix-socket /var/run/docker.sock http://localhost/version
gh act -vIn the end, these are the commands that I've used to fix the problem on Fedora 39 using Podman:
systemctl enable --user --now podman.socket podman.service
sudo ln -sf /run/user/$EUID/podman/podman.sock /var/run/docker.sockNotice that this is an acceptable workaround for me, since I'm the only user who uses act & podman on my computer, but it may not work if multiple unprivileged users need to use act & podman on the same computer, because the user socket only has permissions for that specific user.
mmv08
commented
5 months ago 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.
docker context ls
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock
desktop-linux * moby Docker Desktop unix:///home/mmv/.docker/desktop/docker.sockls -l /var/run/docker.sock
ls: cannot access '/var/run/docker.sock': No such file or directorysudo ln -s $HOME/.docker/desktop/docker.sock /var/run/docker.sockThe solution is taken from this thread on the docker forum: https://forums.docker.com/t/is-a-missing-docker-sock-file-a-bug/134351
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