Podman volume mounts, rootless container, and non-root user in container

I am working with the official ISC Bind9 container image (which appears to be based on Debian Linux though it says Alpine), and I’m having trouble with permissions and mounted voumes:

I start the container with mounts in my user-mode account as follows:

podman run --name bind9 \
-p 11153:53/udp \
-p 11153:53/tcp \
-v /home/devops/work/dns/primary/etc:/etc/bind/:rw,Z \
-v /home/devops/work/dns/primary/cache:/var/cache/bind:rw,Z, \
-v /home/devops/work/dns/primary/lib:/var/lib/bind:rw,Z, \
-v /home/devops/work/dns/primary/log:/var/log:rw,Z, \
internetsystemsconsortium/bind9:9.20 -4 -g -c /etc/bind/named.conf

There are no podman logs to reference, so I set the -g flag on named binary so that errors go to stderr. The container starts but exits with error code 1 after about 3 seconds, and I get the following error messages that appear to be access issues between my host and the container???

09-Nov-2024 21:26:44.329 the working directory is not writable
09-Nov-2024 21:26:44.330 loading configuration: permission denied
09-Nov-2024 21:26:44.330 exiting (due to fatal error)

Digging into the container layers, I see that in the container a bind user is used to run named in the ENTRYPOINT part of the container.

...
23 VOLUME [/etc/bind /var/cache/bind /var/lib/bind /var/log] 0 B
24 EXPOSE map[443/tcp:{} 53/tcp:{} 53/udp:{} 853/tcp:{} 0 B
25 ENTRYPOINT ["/usr/sbin/named" "-u" "bind"] 0 B
26 CMD ["-f" "-c" "/etc/bind/named.conf" "-L" 0 B
...

After much searching around the Internet, I understand this is because from the perspective of execution environment inside the container, these mounted volumes have root:root permissions, but the container was built but ISC for use with a bind user. I suppose if I was running Docker rather than Podman this would just work?

So after some more digging, I was able to get the UID and GID of the bind user inside the container by not mounting any volumes and then spawning a shell in the container execution environment.

podman run -d --name=bind9 -p 11153:53/udp -p 11153:53/tcp internetsystemsconsortium/bind9:9.20
podman exec -it bind9 /bin/sh
/ # cat /etc/passwd...
bind:x:100:101:Linux User,,,:/var/cache/bind:/sbin/nologin

After more Internet research and RedHat reading, it seems I should use the --userns option on podman to map the mounted volumes with the bind user in the container. I tried adding --userns=keep-id:uid=100,gid=101 to the podman run command but I still get the same exact errors.

At this point I tried a “hail mary” and on the host machine I made the volumes chmod 777, but I still get the same exact errors.

I’m not sure what to try next…do I have to create a useless bind user account on the host and somehow map the UID and GID to the container? These seems like an extraneous step and that there should be something I can do with podman to handle this…but I don’t know.

This is a very interesting question, how this mounts work.
The example above mounts the the folder “/home/devops/work/dns/primary/etc” of the host file system into the container under “/etc/bind/”.
AFAIK this will override the content of the of the containers folder with the host files.
If there are no config files in the host directory under …primary/etc/… then you most likely end up with an empty /etc/bind/-folder in the container and the container may not start.

In my experience it is better to use

podman volume create bind-config

and a storage will be created by podman in rootless mode under

$HOME/.local/share/containers/storage/volumes/bind-config/_data

This method will provide you with the containers config files and with correct permissions.

You can attach the volume to the container like this:
-v bind-config:/etc/bind:Z \
(notice the missing ‘/’ at the end of the containers path, you can leave the rw-option as well)

Edit
Where the storage of the volume is created depends on the “storage.conf” and weather you use Podman rootless or not. If you want to know where the volume is created, you can use podman inspect bind-config. Or you can read the configuration with podman info.

2 Likes

That you this helped me get past the hurdle and it certainly makes a lot of sense now for running rootless containers going forward! Learned a lot from this.

1 Like