On Fedora 44: My named a.k.a bind program (a DNS resolver) could not load some zones. It was caused by incorrect group owner of /usr/share/named (was root, should be named). I corrected it, but later it happened again. I started to investigate who is changing the ownership of that dir.
Its ctime exactly corresponds to the time a DNF upgrade was running. I can now reproduce it:
verify that the GID of /usr/share/named is the named group
run dnf reinstall man-db
now the GID of /usr/share/named is the root group!
Further I was able to verify that the triggered RPM scripts are to blame. I guess either glibc-common or systemd are doing it. It is very unlikely, that man-db has something to do with that directory.
And this is where I stopped. I don’t know how to check those scriplets and I don’t have much free time for this issue.
Normaly I would file a bug, but don’t know against which component.
I would appreciate if someone could continue tracking the bug down. Or at least answer the question from the title - how to debug those “scriplets”?
I see root:root ownership but my chroot-named.service runs without error.
The ownership being root:root does not stop named as it does not need to write to that folder.
Which named service are you using and where are your zone files stored?
I’m also using named-chroot. Zones not loaded are the built-in zones. You might not notice the problem at all without checking the logs. Here is a log snippet where it all started:
15.05.2026 00:54:01.197 named: zone 1.0.0.127.in-addr.arpa/IN/internal: loading from master file /usr/share/named/named.loopback failed: permission denied
15.05.2026 00:54:01.213 named: zone 1.0.0.127.in-addr.arpa/IN/internal: not loaded due to errors.
15.05.2026 00:54:01.214 named: zone 0.in-addr.arpa/IN/internal: loading from master file /usr/share/named/named.empty failed: permission denied
15.05.2026 00:54:01.214 named: zone 0.in-addr.arpa/IN/internal: not loaded due to errors.
15.05.2026 00:54:01.214 named: zone localhost.localdomain/IN/internal: loading from master file /usr/share/named/named.localhost failed: permission denied
15.05.2026 00:54:01.214 named: zone localhost.localdomain/IN/internal: not loaded due to errors.
15.05.2026 00:54:01.214 named: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/internal: loading from master file /usr/share/named/named.loopback failed: permission denied
15.05.2026 00:54:01.214 named: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/internal: not loaded due to errors.
15.05.2026 00:54:01.219 named: zone localhost/IN/internal: loading from master file /usr/share/named/named.localhost failed: permission denied
15.05.2026 00:54:01.219 named: zone localhost/IN/internal: not loaded due to errors.
The directory has mode 0750 (rwxr-x—), intended owner root:named, so named should be able to read files from there, but not write. You can also check with the rpm -qV bind command.
2026-05-22T12:23:52+01:00 named[1135]: automatic empty zone: HOME.ARPA
2026-05-22T12:23:52+01:00 named[1135]: automatic empty zone: RESOLVER.ARPA
2026-05-22T12:23:52+01:00 named[1135]: command channel listening on 127.0.0.1#953
2026-05-22T12:23:52+01:00 named[1135]: command channel listening on ::1#953
2026-05-22T12:23:52+01:00 named[1135]: managed-keys-zone: loaded serial 1086
2026-05-22T12:23:52+01:00 named[1135]: zone 0.in-addr.arpa/IN: loaded serial 0
2026-05-22T12:23:52+01:00 named[1135]: zone 1.17.172.IN-ADDR.ARPA/IN: loaded serial 13601
2026-05-22T12:23:52+01:00 named[1135]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
2026-05-22T12:23:52+01:00 named[1135]: zone internal/IN: loaded serial 20957
2026-05-22T12:23:52+01:00 named[1135]: zone localhost/IN: loaded serial 0
2026-05-22T12:23:52+01:00 named[1135]: zone 2.17.172.IN-ADDR.ARPA/IN: loaded serial 12001
2026-05-22T12:23:52+01:00 named[1135]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
2026-05-22T12:23:52+01:00 named[1135]: zone home/IN: loaded serial 12001
2026-05-22T12:23:52+01:00 named[1135]: zone localhost.localdomain/IN: loaded serial 0
2026-05-22T12:23:52+01:00 systemd[1]: Started named-chroot.service - Berkeley Internet Name Domain (DNS).
Yesterday I managed to find the command doing it, it’s systemd-tmpfiles --create. It changes the group of my /usr/share/named. The funny thing is, that --dry-run does not show it, nor could I find something related in the configuration. To be continued…
Side note: I’m a new user here. With new informations arriving during the discussion, the topic drifted from RPM scriplets to named/bind file permissions. Should I change the title? Should I start a new thread? Thanks.
I think you have found a bug that the permission and ownership is not set correctly. Please report that to Fedora against the bind package. See Making sure you're not a bot!
The named config is likely down to your requirements and my requirements being different. We could named config in a new topic and see what we discover.
The targets are all under /var/named, but is it possible that those paths on your install symlink back to /usr/share, like for the reporter of this bug?
Notice that when named runs with chroot /var/named/chroot, the file names as reported by named are without the /var/named/chroot/ prefix. So when named looks at the file /usr/share/named it is really looking at /var/named/chroot/usr/share/named and not /usr/share/named.
I could not dedicate my time to this issue today. I did not even read all posts thoroughly yet. It looks like your findings are similar to mine, but one thing I’d like to add is that /var/named/chroot/usr/share/named is identical to usr/share/named via mount --bind. So changing the ownership of former by systemd-tmpfiles effectively changes the latter.
That is the important point. The bind mounts are all set up using the setup-named-chroot.sh script called from named-chroot-setup.service.
I don’t know why /usr/lib/tmpfiles.d/bind-chroot.conf was created, but it seems to me to be entirely unnecessary as all the directories it would create are all provided by the bind-chroot package and need not be re-created at boot time.
By the way, the rpm script responsible for relabeling the file is a file trigger in the systemd package. This means, that whenever a file is installed or modified in the directory /usr/lib/tmpfiles.d/ the command systemd-tmpfiles --create is run.