[johnchristopher]

> Permission issues with bind mounts just totally disappear when you go rootless.

I have a problem with mounting a named foo in a container (at /foo) and bindfsing the underlying directory of that volume on ${HOME}/foo with create-for parameters so that when the host user touch files in it they are owned by host 1000:1000 but inside the container it's owned by 33:33.

Volume foo really contains only a unix socket. This unix socket is shared between the host and the container for xdebug communication.

So, this doesn't work, the container process can't write/read the socket even though it can manipulate other files in the mounted volumes /foo and they appear as owned by 1000:1000 on the host and vice versa.

But if I mount the volume directly like that: ${HOME}/foo:/foo then it works and the container can write to the socket and the host and the container can communicate both ways.

Would rootless podman allow me to use a named volume ? Why doesn't it work like I think it should, is it because the unix socket lives in the kernel 'or something' ? Maybe it's a question for SO.

[krageon]

It probably is a question for SO, where it would be best described with a script that sets up the minimum environment required to reproduce and the situation that you want to achieve. This description doesn't quite get me to an understanding of the problem, but that may be a personal issue.

[dhzhzjsbevs]

Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's.

[johnchristopher]

> Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's.

Oh, I tried running the process in the container under a different uid but it complained about unprivileged user. Going the other way may do it, thanks. Although it requires more fiddling with stock images.