I suspect that this is a ‘capabilities’ issue, rather than a simple file permissions problem.
After upgrading Tumbleweed today, named.service (DNS server) doesn’t run anymore. The error says:
17-Feb-2020 20:12:37.313 loading configuration from ‘/etc/named.conf’
17-Feb-2020 20:12:37.314 directory ‘/var/lib/named’ is not writable
17-Feb-2020 20:12:37.314 /etc/named.conf:21: parsing failed: permission denied
17-Feb-2020 20:12:37.314 loading configuration: permission denied
That directory has reasonable permissions and ownership:
% ls -ld /var/lib/named
drwxr-xr-x 1 named named 222 Feb 17 20:04 /var/lib/named
Setting it to 775 doesn’t fix things. However, setting it to 777 does, and gets me to the next problem:
17-Feb-2020 20:13:57.888 managed-keys-directory ‘/var/lib/named/dyn/’ is not writable
17-Feb-2020 20:13:57.891 loading configuration: permission denied
Looking at the run (via “strace named -g”), I don’t see anything that looks like a permissions problem at all. No obvious errors, in fact.
I tried disabling AppArmor (because that’s almost always a cause of problems, at least for me), and that did nothing. I am NOT using SELinux. Before the upgrade (“zypper -n dup --no-recommends --auto-agree-with-licenses --replacefiles --allow-vendor-change”), the system was running correctly, including named.service.
Here’s the only (really horrible!) work-around I’ve found that brings named back to life:
chmod 777 /var/lib/named /var/lib/named/dyn
Obviously, that can’t be a long-term solution. But at least I’m back up and running.
I searched this forum and the bug reports to see if there was anything similar. I found nothing. I searched via google, and found users who had fat-fingered configuration files, but that’s not the issue here. Something about the directory access or permissions model has gone haywire.