/var/run/docker.sock:/tmp/docker.sock:ro big problem for rootless docker

[airdogvan]

I run quite a few servers and all of them use your code as reverse-proxy. As mentioned in the title I run everything (including the reverse-proxy) rootless for security reasons.

This new version acme-companion issues an error (see above) because of the mapping to the docker socket.

I'm wondering: does the left side of the mapping really matter to the program? Rootless locates the doker socket elsewhere (by default /run/user/UID/docker.sock). I locate it somewhere else but again does it really matter to acme where on the host the docker socket is located?

If not I would be immensely beneficial for me if you could not check the left side of the mapping, just the right side. By the way I tried to map the right side to /tmp/docker.sock:ro but acme still issued and error and had to revert to /var/run/docker.sock:/var/run/docker.sock:ro

Again I would be immensely grateful if that could be changed. If not I'm stuck at the version I'm running and will never be able to update. (not sure how to check the version but did update about 3 months ago).

Thanks for looking at my post...

[buchdag]

Hi.

I don't get what you mean by "checking the left side of the mapping", this is a Docker bind mount, the left side is where your socket is located on your host, --volume /run/user/UID/docker.sock:/var/run/docker.sock:ro should work if you Docker socket is located at /run/user/UID/docker.sock. If it does not, this is not because the container "check" the left side value.

What might be confusing is that nginx-proxy and acme-companion both expect the socket to be located in different places inside the running container:

• nginx-proxy expects it at /tmp/docker.sock so --volume /var/run/docker.sock:/tmp/docker.sock:ro
• acme-companion expects it at /var/run/docker.sock so --volume /var/run/docker.sock:/var/run/docker.sock:ro

[airdogvan]

You're right, what I write in the left part shouldn't matter as long as my docker socket is in that location. But the problem is that letsencrypt issues an error saying that the docker socket should be mapped to /var/run/docker.sock.

But I found a workaround which is to modify the Dockerfile:

ENV COMPANION_VERSION=$GIT_DESCRIBE \
    DOCKER_HOST=unix:///var/run/docker.sock \
    PATH=$PATH:/app

and change here the location of /var/run/docker.sock. That worked for me.

But still in principle, letsencrypt shouldn't issue an error because the left side is not located at /var/run/docker.sock. Only if the RIGHT side is not /var/run/docker.sock.

[buchdag]

Could you provide the command line or Docker compose file that gives you an error ?

[airdogvan]

sorry to say that this was quite a while ago. Tried to recreate the env on a virtual box without success. I'll let you know if I can reproduce.

And thanks for responding, much appreciated.

[buchdag]

I checked the code again and I can assure you that there is nothing in the code that check the leftmost part of the socket bind mount.

Again --volume /run/user/$UID/docker.sock:/var/run/docker.sock:ro should work without any modification of anything.

The important thing is that you keep the right part identical to what the image expect be default (:/var/run/docker.sock:ro) but the left part (and the left part only) can be any path to a valid Docker socket on your host machine.

--volume /run/user/$UID/docker.sock:/run/user/$UID/docker.sock:ro on the other and will not work out of the box : if you really want or need to change the in-container Docker socket location (the right part of the bind mount), you can just provide DOCKER_HOST as an environment variable to the container, no need to modify the Dockerfile.

Example:

docker run --detach \
    --name nginx-proxy-acme \
    --volumes-from nginx-proxy \
    --volume acme:/etc/acme.sh \
    --env "DOCKER_HOST=unix:///foo/bar/docker.sock" \
    --volume /run/user/$UID/docker.sock:/foo/bar/docker.sock:ro \
    nginxproxy/acme-companion

I'm closing this for now because there really isn't anything on the code that check the leftmost part of the socket bind mount against a known value, and I was unable to reproduce this issue. Feel free to re-open if you're able to reproduce.

[airdogvan]

@buchdag thank you again for making sure. That might explain why I can't reproduce this error.

I've been using acme-companion for quite a while now and was very surprised when I did get this error.

Is it possible that the code has since been modified? It's also possible of course that I made a mistake, although at the time I checked many many times. And I also remember quite clearly having copied/paste the mapping from the nginx config to acme-companion and still getting that error.

In any case, thank you again for rechecking! Much obliged.

[JohnMertz]

For future Googlers, I had the same issue when running this in Fedora CoreOS 40. In my case, it's not that the socket doesn't get bound, it is that it is not readable because of SELinux. (discovered by temporarily adding command: "ls -alh /var/run/docker.sock" to the compose file and seeing permissions ?????????). You need to mount with the ':z' suffix instead of ':ro'. This probably applies to anyone running a system with SELinux enabled (perhaps this is what changed on the OP's machine).

Otherwise the previous advice is correct, you just need to give the correct path to your user socket on the left side, like:

volumes:
        - "/var/run/user/1000/podman/podman.sock:/var/run/docker.sock:z"

Note that '/var/run' is actually a symlink to '/run' so you could save yourself 4 characters and just do '/run/docker.sock:z'.

Perhaps this project could be amended to produce a different error for Docker host socket at /var/run/podman.sock is not readable vs. you need to share your Docker host socket with a volume at /var/run/podman.sock. I can make a PR for this, if it is desired.

[buchdag]

@JohnMertz a PR that either amend the original message or add a specific check for this case would be welcome (but the original you need to share your Docker host socket with a volume [...] error must not be removed, that's still a valid one).