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.