resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

NSD fails after Buster upgrade

Mon Aug 05, 2019 7:08 pm

Hi all,

After upgrading from stretch to buster, I noticed my system now claims /var/log/nsd.log is on a read-only file system. It also claims /var/log/nsd.log cannot be opened due to insufficient permissions. But you see, this is a total lie. I'm here to tell on him, hopefully to find a solution to stop him from lying and make him continue to launch my daemons without problems.

Let's see it in action, in syslog:

Code: Select all

[...]
Aug  5 20:56:17 sulaco systemd[1]: Starting Name Server Daemon...
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.529] nsd[3693]: error: Cannot open /var/log/nsd.log for appending (Permission denied), logging to stderr
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.531] nsd[3693]: warning: chown /var/log/nsd.log failed: Read-only file system
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.531] nsd[3693]: notice: nsd starting (NSD 4.1.26)
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.538] nsd[3693]: info: setup SSL certificates
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.645] nsd[3694]: info: zonefile bar.foo.zone.signed is not modified
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.645] nsd[3694]: info: zonefile foo.bar.zone.signed is not modified
Aug  5 20:56:17 sulaco nsd[3693]: [2019-08-05 20:56:17.671] nsd[3694]: notice: nsd started (NSD 4.1.26), pid 3693
Aug  5 20:56:17 sulaco systemd[1]: Started Name Server Daemon.
[...]
Then, let's have a look at this file's permissions:

Code: Select all

$ l /var/log/nsd.log
-rw------- 1 nsd nsd 438K Aug  4 22:10 /var/log/nsd.log
Tthen, also look at the user that is running this daemon:

Code: Select all

 $ ps aux | grep nsd
nsd       3693  0.0  5.8  76184 55532 ?        Ss   20:56   0:00 /usr/sbin/nsd -d
nsd       3694  0.0  3.6  40884 34820 ?        S    20:56   0:00 /usr/sbin/nsd -d
nsd       3695  0.0  0.6  41016  5808 ?        S    20:56   0:00 /usr/sbin/nsd -d
pi    3742  0.0  0.0   7348   568 pts/1    S+   21:03   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nsd
Also, let's verify the root mount point ( I have no separate /var mount point):

Code: Select all

$ mount | grep ' / '
/dev/mmcblk0p2 on / type ext4 (rw,noatime,stripe=32753)
And finally, let's verify root isn't full:

Code: Select all

$ df | grep ' /$'
/dev/root          14425008   10171740   3639268  74% /
Can we assume I've indeed busted my new Buster? How can we stop him from lying?
Last edited by resill on Tue Aug 06, 2019 5:25 pm, edited 1 time in total.

epoch1970
Posts: 8063
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 8:35 pm

Did you actually try to append something to that file, as root?
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 8:57 pm

epoch1970 wrote:
Mon Aug 05, 2019 8:35 pm
Did you actually try to append something to that file, as root?
Yes, and appending succeeded. I'm now suspecting NSD is acting weird.

epoch1970
Posts: 8063
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 9:20 pm

I understand /var/log is handled by systemd. I'm not accusing it, but you know...
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

User avatar
Imperf3kt
Posts: 4675
Joined: Tue Jun 20, 2017 12:16 am
Location: Australia

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 9:23 pm

resill wrote:
Mon Aug 05, 2019 8:57 pm
epoch1970 wrote:
Mon Aug 05, 2019 8:35 pm
Did you actually try to append something to that file, as root?
Yes, and appending succeeded. I'm now suspecting NSD is acting weird.
Did you also reboot and check the file was still the same after that?
55:55:44:44:4C
52:4C:52:42:41

Rose tinted glasses are difficult to see through.

trejan
Posts: 4929
Joined: Tue Jul 02, 2019 2:28 pm

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 9:32 pm

epoch1970 wrote:
Mon Aug 05, 2019 9:20 pm
I understand /var/log is handled by systemd. I'm not accusing it, but you know...
systemd sends it to rsyslog which writes to the files in /var/log but in this case, it looks like NSD is writing its log file directly.

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Mon Aug 05, 2019 9:43 pm

I don't have nsd installed anywhere, but one thing I ran into recently was trying to start a service before the file system had been remounted read/write. I doubt that this is the issue with nsd, but mentioning for completeness. I ended up doing After=local-fs-pre.target to make it work.

Is nsd running chrooted (-t chroot dir)? Didn't look like it was, but trying to offer things that might be possible issues

One thing to try would be to redirect the log file to another file with chmod 777 protection, which would validate whether it's a file protection issue or not.
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 10:40 am

Imperf3kt wrote:
Mon Aug 05, 2019 9:23 pm

Did you also reboot and check the file was still the same after that?

Rebooting did not revert my writes. I can still see the stuff I appended manually to /var/log/nsd.log.
Last edited by resill on Tue Aug 06, 2019 10:59 am, edited 1 time in total.

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 10:57 am

bls wrote:
Mon Aug 05, 2019 9:43 pm
I don't have nsd installed anywhere, but one thing I ran into recently was trying to start a service before the file system had been remounted read/write. I doubt that this is the issue with nsd, but mentioning for completeness. I ended up doing After=local-fs-pre.target to make it work.

Is nsd running chrooted (-t chroot dir)? Didn't look like it was, but trying to offer things that might be possible issues

One thing to try would be to redirect the log file to another file with chmod 777 protection, which would validate whether it's a file protection issue or not.
I have not set NSD to run in a chroot jail, as I have not set the 'chroot:' directive in nsd.conf. chmod 777 /var/log/nsd.log did not have any affect, but configuring 'logfile: "/etc/nsd/nsd.log"' instead, did work. It seems NSD has no problems writing in /etc/nsd, but for some reason it cannot write to /var/log/nsd.log, regardless of file permissions. I also moved the new /etc/nsd/nsd.log to /var/log/nsd.log and reverted the logfile directive to /var/log/nsd.log in nsd.conf. Didn't help either.

Also, I failed to mention that I had to chmod 666 /var/lib/nsd/zone.list to even get NSD to start in the first place. When /var/lib/nsd/zone.list is set to chmod 600, it for some reason cannot read this file, even though the nsd user is the owner of this file. So, as a temporary work-around I chmod 666 /var/lib/nsd/zone.list, launch NSD, and then chmod 600 /var/lib/nsd/zone.list back to its intended permissions, but this also does not make sense to me *at all*.

Have a look at its owner, group and permissions:

Code: Select all

$ l /var/lib/nsd/zone.list
-rw------- 1 nsd nsd 83 Oct 27  2016 /var/lib/nsd/zone.list
And then starting NSD results in this error in syslog:

Code: Select all

Aug  6 12:54:44 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 12:54:44 sulaco nsd[2125]: [2019-08-06 12:54:44.810] nsd[2125]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 12:54:44 sulaco nsd[2125]: [2019-08-06 12:54:44.810] nsd[2125]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 12:54:44 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 12:54:44 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 12:54:44 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 12:54:44 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 12:54:44 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 3.
Aug  6 12:54:44 sulaco systemd[1]: Stopped Name Server Daemon.
Yet when I change this back to chmod 666 /var/lib/nsd/zone.list, then NSD can start, but keeps complaining it cannot write to /var/log/nsd.log.

Surely I must be missing something... :(

epoch1970
Posts: 8063
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 11:35 am

The 2 issues seem connected.
What does "id nsd" report?
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 11:41 am

epoch1970 wrote:
Tue Aug 06, 2019 11:35 am
The 2 issues seem connected.
What does "id nsd" report?

Code: Select all

$ id nsd
uid=125(nsd) gid=133(nsd) groups=133(nsd),129(opendnssec)
Seem to be ok, right?

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 2:17 pm

Just for grins I installed nsd on a freshyly installed Buster system that is NOT running rsyslog (journalctl doesn't forward to rsyslog), and /var/log/nsd.log was NOT created. One experiment you could try zero in on the issue is to replicate this on your system:

Code: Select all

sudo sed -i "s/\#ForwardToSyslog=yes/ForwardToSyslog=no/" /etc/systemd/journald.conf
sudo systemctl disable rsyslog.service
and reboot. nsd shouldn't try to write to /var/log/nsd.log then.

If you want to revert back to using rsyslog after this test, do:

Code: Select all

sudo sed -i "s/\#ForwardToSyslog=no/ForwardToSyslog=yes/" /etc/systemd/journald.conf
sudo systemctl enable rsyslog.service
If you try this, it would be helpful to see the journalctl output from nsd. Here's what I found in my log (using journalctl):

Code: Select all

Aug 06 06:46:14 rpi31 systemd[1]: Starting Name Server Daemon...
Aug 06 06:46:15 rpi31 nsd[3453]: nsd starting (NSD 4.1.26)
Aug 06 06:46:15 rpi31 nsd[3453]: [2019-08-06 06:46:15.097] nsd[3453]: notice: nsd starting (NSD 4.1.26)
Aug 06 06:46:15 rpi31 nsd[3454]: nsd started (NSD 4.1.26), pid 3453
Aug 06 06:46:15 rpi31 nsd[3453]: [2019-08-06 06:46:15.248] nsd[3454]: notice: nsd started (NSD 4.1.26), pid 3453
Aug 06 06:46:15 rpi31 systemd[1]: Started Name Server Daemon.
Aug 06 06:46:52 rpi31 nsd[3454]: signal received, shutting down...
Aug 06 06:46:52 rpi31 nsd[3453]: [2019-08-06 06:46:52.969] nsd[3454]: warning: signal received, shutting down...
Aug 06 06:46:52 rpi31 nsd[3453]: [2019-08-06 06:46:52.970] nsd[3454]: warning: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 06:46:52 rpi31 nsd[3454]: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 06:46:52 rpi31 systemd[1]: Stopping Name Server Daemon...
Aug 06 06:46:53 rpi31 systemd[1]: nsd.service: Succeeded.
Aug 06 06:46:53 rpi31 systemd[1]: Stopped Name Server Daemon.
As you can see, nsd started fine. It did get an error on the pid file when it shut down, but the file isn't there now, so not sure what's happening with that :?
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 2:33 pm

bls wrote:
Tue Aug 06, 2019 2:17 pm
Just for grins I installed nsd on a freshyly installed Buster system that is NOT running rsyslog (journalctl doesn't forward to rsyslog), and /var/log/nsd.log was NOT created. One experiment you could try zero in on the issue is to replicate this on your system:

Code: Select all

sudo sed -i "s/\#ForwardToSyslog=yes/ForwardToSyslog=no/" /etc/systemd/journald.conf
sudo systemctl disable rsyslog.service
and reboot. nsd shouldn't try to write to /var/log/nsd.log then.

If you want to revert back to using rsyslog after this test, do:

Code: Select all

sudo sed -i "s/\#ForwardToSyslog=no/ForwardToSyslog=yes/" /etc/systemd/journald.conf
sudo systemctl enable rsyslog.service
If you try this, it would be helpful to see the journalctl output from nsd. Here's what I found in my log (using journalctl):

Code: Select all

Aug 06 06:46:14 rpi31 systemd[1]: Starting Name Server Daemon...
Aug 06 06:46:15 rpi31 nsd[3453]: nsd starting (NSD 4.1.26)
Aug 06 06:46:15 rpi31 nsd[3453]: [2019-08-06 06:46:15.097] nsd[3453]: notice: nsd starting (NSD 4.1.26)
Aug 06 06:46:15 rpi31 nsd[3454]: nsd started (NSD 4.1.26), pid 3453
Aug 06 06:46:15 rpi31 nsd[3453]: [2019-08-06 06:46:15.248] nsd[3454]: notice: nsd started (NSD 4.1.26), pid 3453
Aug 06 06:46:15 rpi31 systemd[1]: Started Name Server Daemon.
Aug 06 06:46:52 rpi31 nsd[3454]: signal received, shutting down...
Aug 06 06:46:52 rpi31 nsd[3453]: [2019-08-06 06:46:52.969] nsd[3454]: warning: signal received, shutting down...
Aug 06 06:46:52 rpi31 nsd[3453]: [2019-08-06 06:46:52.970] nsd[3454]: warning: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 06:46:52 rpi31 nsd[3454]: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 06:46:52 rpi31 systemd[1]: Stopping Name Server Daemon...
Aug 06 06:46:53 rpi31 systemd[1]: nsd.service: Succeeded.
Aug 06 06:46:53 rpi31 systemd[1]: Stopped Name Server Daemon.
As you can see, nsd started fine. It did get an error on the pid file when it shut down, but the file isn't there now, so not sure what's happening with that :?

Thanks for also trying out NSD. Sadly, I'm still getting the same error:

Code: Select all

Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.155] nsd[624]: error: Cannot open /var/log/nsd.log for appending (Read-only file system), logging to stderr
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.157] nsd[624]: warning: chown /var/log/nsd.log failed: Read-only file system
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.157] nsd[624]: notice: nsd starting (NSD 4.1.26)
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.168] nsd[624]: info: setup SSL certificates
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.221] nsd[624]: error: cannot open pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.221] nsd[624]: error: cannot overwrite the pidfile /run/nsd/nsd.pid: Permission denied
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.439] nsd[699]: info: zonefile bar.foo.zone.signed is not modified
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.440] nsd[699]: info: zonefile foo.bar.zone.signed is not modified
Aug 06 16:29:18 sulaco nsd[624]: [2019-08-06 16:29:18.441] nsd[699]: notice: nsd started (NSD 4.1.26), pid 624
Aug 06 16:29:18 sulaco systemd[1]: Started Name Server Daemon.
As well as those pidfile errors you get as well. Wth is wrong with my system :(

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 2:48 pm

Please post your /etc/nsd/nsd.conf and any config files in /etc/nsd/nsd.conf.d
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 2:57 pm

bls wrote:
Tue Aug 06, 2019 2:48 pm
Please post your /etc/nsd/nsd.conf and any config files in /etc/nsd/nsd.conf.d
Of course, although I've made some minor changes to not show my personal information (e.g. global ipv6 address, domain names). :)

nsd.conf:

Code: Select all

$ cat /etc/nsd/nsd.conf
# NSD configuration file for Debian.
#
# See the nsd.conf(5) man page.
#
# See /usr/share/doc/nsd/examples/nsd.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/nsd/nsd.conf.d directory.

include: "/etc/nsd/nsd.conf.d/*.conf"
nsd.conf.d/foobar.conf:

Code: Select all

$ cat /etc/nsd/nsd.conf.d/foobar.conf 
server:
	ip-address: 192.168.178.10
	ip-address: [my ipv6 address]
	logfile: "/var/log/nsd.log"
	# logfile: "/etc/nsd/nsd.log"
	verbosity: 5
	username: nsd
pattern:
	name: "myzones"
	zonefile: "%s.zone.signed"
zone.list:

Code: Select all

$ cat /var/lib/nsd/zone.list            
# NSD zone list
# name pattern
add bar.foo myzones
add foo.bar myzones

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 3:03 pm

I notice that you have logfile: "/var/log/nsd.log" in one of your config files. In the fresh nsd install on my system, it's not there, and it's commented out in the sample config file in /usr/share/doc/nsd/examples.

What is the result if you comment that line out completely in yours?
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 3:22 pm

bls wrote:
Tue Aug 06, 2019 3:03 pm
I notice that you have logfile: "/var/log/nsd.log" in one of your config files. In the fresh nsd install on my system, it's not there, and it's commented out in the sample config file in /usr/share/doc/nsd/examples.

What is the result if you comment that line out completely in yours?
I commented that line out and now it doesn't log to /var/log/nsd.log, of course. And according to syslog I still cannot start nsd.service with /var/lib/nsd/zone.list set to its proper permissions (i.e. not to 666):

Code: Select all

$ sudo chmod 600 /var/lib/nsd/zone.list
$ l /var/lib/nsd/zone.list          
-rw------- 1 nsd nsd 83 Oct 27  2016 /var/lib/nsd/zone.list
$ sudo systemctl restart nsd.service   
Job for nsd.service failed because the control process exited with error code.
See "systemctl status nsd.service" and "journalctl -xe" for details.
when unsuccefully restarting NSD, syslog says:

Code: Select all

Aug  6 17:20:39 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 17:20:39 sulaco nsd[2512]: [2019-08-06 17:20:39.891] nsd[2512]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 17:20:39 sulaco nsd[2512]: [2019-08-06 17:20:39.891] nsd[2512]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 17:20:39 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:20:39 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:39 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 1.
Aug  6 17:20:40 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 17:20:40 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 17:20:40 sulaco nsd[2523]: [2019-08-06 17:20:40.585] nsd[2523]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 17:20:40 sulaco nsd[2523]: [2019-08-06 17:20:40.585] nsd[2523]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:40 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 17:20:40 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 2.
Aug  6 17:20:40 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 17:20:40 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 17:20:41 sulaco nsd[2526]: [2019-08-06 17:20:41.209] nsd[2526]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 17:20:41 sulaco nsd[2526]: [2019-08-06 17:20:41.210] nsd[2526]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:41 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 3.
Aug  6 17:20:41 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 17:20:41 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 17:20:41 sulaco nsd[2530]: [2019-08-06 17:20:41.881] nsd[2530]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 17:20:41 sulaco nsd[2530]: [2019-08-06 17:20:41.882] nsd[2530]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:20:41 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:41 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 4.
Aug  6 17:20:42 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 17:20:42 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 17:20:42 sulaco nsd[2533]: [2019-08-06 17:20:42.539] nsd[2533]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 17:20:42 sulaco nsd[2533]: [2019-08-06 17:20:42.539] nsd[2533]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:42 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 5.
Aug  6 17:20:42 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Start request repeated too quickly.
Aug  6 17:20:42 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 17:20:42 sulaco systemd[1]: Failed to start Name Server Daemon.
In other words, all this does is stopping nsd from writing to its own logfile in /var/log/nsd.log.

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 4:01 pm

resill wrote:
Tue Aug 06, 2019 3:22 pm
In other words, all this does is stopping nsd from writing to its own logfile in /var/log/nsd.log.
Great news! This solves the logfile protection problem. A few things to try:

1) Make sure that the protection on the directory /var/lib/nsd is 755 and owned by nsd.nsd
2) If that's fine, try opening up the protection on /var/lib/nsd/zone.list to 777 and see what happens
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 4:15 pm

bls wrote:
Tue Aug 06, 2019 4:01 pm
resill wrote:
Tue Aug 06, 2019 3:22 pm
In other words, all this does is stopping nsd from writing to its own logfile in /var/log/nsd.log.
Great news! This solves the logfile protection problem. A few things to try:

1) Make sure that the protection on the directory /var/lib/nsd is 755 and owned by nsd.nsd
2) If that's fine, try opening up the protection on /var/lib/nsd/zone.list to 777 and see what happens
Except this doesn't actually solve any problem, because we still don't know why NSD cannot log to its own file in /var/log/nsd.log, with its permissions and ownsership set right. This should simply be possible, and I cannot pinpoint any errors in my configuration to facilitate this, and still it doesn't work, god knows why. This still does not make sense to me at all and I need to know wth is going on before I lose my sanity (slightly over exaggerated).

Also, /var/lib/nsd is already set to 755 and owned by nsd:nsd:

Code: Select all

$ l -d /var/lib/nsd 
drwxr-xr-x 2 nsd nsd 4.0K Jun  7  2017 /var/lib/nsd
And I've already mentioned that chmod 666 /var/lib/nsd/zone.list works - there's no point in setting it to 777 because we've already established this works. The thing is: it shouldn't need to be set to 666, let alone 777, because it already has ownership and user permissions set to rw! Likewise, it should never be recommended or acceptable to set chmod 777 /etc/shadow if PAM does not work without it...

epoch1970
Posts: 8063
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 4:46 pm

I see this opened bug:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=915227
Perhaps you want to check ps and see if your server is started w/ '-d'?
I've also seen a *closed* bug about nsd (launch scripts I guess) chowning its own files to 0:0 and thereafter failing to read them...

I think I would disable the service, check all files are ok, reboot, run the server manually from the command line as the init script would do.
If it's unhappy IMHO that's a package or source code bug.

If it's happy, clean reboot again and start it manually via the systemd service unit ("systemctl start nsd-or-something-like-that")
If it fails there the issue is in the unit file (or maybe an init file if it still exists.)

If it succeeds, there might be a startup order issue with good old systemd.

Good luck.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 5:02 pm

resill wrote:
Tue Aug 06, 2019 4:15 pm

Except this doesn't actually solve any problem, because we still don't know why NSD cannot log to its own file in /var/log/nsd.log, with its permissions and ownsership set right.
Oh, you didn't say you wanted to find and resolve the root problem...thought you just focused on getting nsd working. :o

There's obviously something dorked on your system from the upgrade process. As I've demonstrated, installing nsd on a fresh Buster works fine. This is one of the 7,436,294 reasons that I don't do upgrades. There are just too many things that can go wrong. It could also be something that you did to your pre-upgrade system that is causing this issue (been there, done that :oops: )

In fact, if you read https://www.raspberrypi.org/blog/buster ... -raspbian/, they said "We do not recommend upgrading an existing Stretch (or earlier) system to Buster – we can’t know what changes everyone has made to their system, and so have no idea what may break when you move to Buster."

Upgrading is always risky. Heck, I've been using Windows for an embarrasingly long time, and it's only with Win 10 that I stopped doing clean installs at every release and have embraced upgrades. Upgrades are hard for the system developers to get 100% right. There are too many things that they themselves do and forget to handle as part of the upgrade (thinking more about Windows here, but Linux has it's share of these). And let's not forget the unlimited things that we users do to our systems (both Windows and Linux). :lol:

One last suggestion, if you haven't tried it, is to apt-get remove nsd and then install it again. nsd seems to have been developed by folks who pay a lot of attention to details (geez, take a look at /lib/systemd/system/nsd.service :shock: ), so maybe reinstalling it will fix whatever is broken from the upgrade.

Lastly, please change the name of this thread. A much more appropriate and useful title would be "nsd fails after Buster upgrade". It works fine on a clean install, and Buster isn't "lying" about read-only file systems.

Thanks
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 5:25 pm

epoch1970 wrote:
Tue Aug 06, 2019 4:46 pm
I see this opened bug:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=915227
Perhaps you want to check ps and see if your server is started w/ '-d'?
I've also seen a *closed* bug about nsd (launch scripts I guess) chowning its own files to 0:0 and thereafter failing to read them...

I think I would disable the service, check all files are ok, reboot, run the server manually from the command line as the init script would do.
If it's unhappy IMHO that's a package or source code bug.

If it's happy, clean reboot again and start it manually via the systemd service unit ("systemctl start nsd-or-something-like-that")
If it fails there the issue is in the unit file (or maybe an init file if it still exists.)

If it succeeds, there might be a startup order issue with good old systemd.

Good luck.
NSD is indeed launched with '-d':

Code: Select all

$ ps aux | grep nsd
nsd       2901  0.0  5.9  76184 56104 ?        Ss   18:08   0:00 /usr/sbin/nsd -d
nsd       2902  0.0  3.7  41140 35368 ?        S    18:08   0:00 /usr/sbin/nsd -d
nsd       3228  0.0  0.2  41416  2692 ?        S    18:38   0:00 /usr/sbin/nsd -d
pi    3401  0.0  0.0   7348   528 pts/1    S+   18:52   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nsd
nsd.service file permissions and contents:

Code: Select all

$ l /lib/systemd/system/nsd.service    
-rw-r--r-- 1 root root 735 Aug  4 21:11 /lib/systemd/system/nsd.service
$ cat /lib/systemd/system/nsd.service 
[Unit]
Description=Name Server Daemon
Documentation=man:nsd(8)
After=network.target

[Service]
Type=notify
Restart=always
ExecStart=/usr/sbin/nsd -d
ExecReload=+/bin/kill -HUP $MAINPID
CapabilityBoundingSet=CAP_CHOWN CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_CHROOT
MemoryDenyWriteExecute=true
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=strict
ReadWritePaths=/var/lib/nsd /etc/nsd /run
RuntimeDirectory=nsd
RestrictRealtime=true
SystemCallArchitectures=native
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module mount @obsolete @resources

[Install]
WantedBy=multi-user.target
Should be correct, yes?

Now, the nsd user cannot launch NSD itself because it cannot bind to 53/udp:

Code: Select all

$ sudo su -s /bin/bash nsd
nsd@sulaco:~$ /usr/sbin/nsd -d
[2019-08-06 19:00:56.845] nsd[3857]: notice: nsd starting (NSD 4.1.26)
[2019-08-06 19:00:56.845] nsd[3857]: error: can't bind udp socket: Permission denied
[2019-08-06 19:00:56.845] nsd[3857]: error: server initialization failed, nsd could not be started
So, I'm assuming NSD is launched as root, which then binds to 53/udp, and then drops its root privs and continues to run as the nsd user. Proceeding with this, when launching as root (sudo), it can read all its files just fine, except for its damn pidfile...:

Code: Select all

$ sudo /usr/sbin/nsd -d             
[2019-08-06 19:13:04.677] nsd[4159]: notice: nsd starting (NSD 4.1.26)
[2019-08-06 19:13:04.685] nsd[4159]: info: setup SSL certificates
[2019-08-06 19:13:04.687] nsd[4159]: error: cannot open pidfile /run/nsd/nsd.pid: No such file or directory
[2019-08-06 19:13:04.688] nsd[4159]: error: cannot overwrite the pidfile /run/nsd/nsd.pid: No such file or directory
[2019-08-06 19:13:04.834] nsd[4160]: info: zonefile kroon.email.zone.signed is not modified
[2019-08-06 19:13:04.834] nsd[4160]: info: zonefile maelstrom.ninja.zone.signed is not modified
[2019-08-06 19:13:04.835] nsd[4160]: notice: nsd started (NSD 4.1.26), pid 4159
But curiously, when launching it using sudo systemctl restart nsd.service, it cannot read its files:

Code: Select all

$ sudo systemctl restart nsd.service
Job for nsd.service failed because the control process exited with error code.
See "systemctl status nsd.service" and "journalctl -xe" for details.
Along with the usual complains in syslog:

Code: Select all

Aug  6 19:15:17 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 19:15:17 sulaco nsd[4203]: [2019-08-06 19:15:17.657] nsd[4203]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 19:15:17 sulaco nsd[4203]: [2019-08-06 19:15:17.659] nsd[4203]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 19:15:17 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 19:15:17 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:17 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 19:15:17 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 19:15:17 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 1.
Aug  6 19:15:17 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 19:15:17 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 19:15:18 sulaco nsd[4214]: [2019-08-06 19:15:18.263] nsd[4214]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 19:15:18 sulaco nsd[4214]: [2019-08-06 19:15:18.263] nsd[4214]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:18 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 2.
Aug  6 19:15:18 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 19:15:18 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 19:15:18 sulaco nsd[4217]: [2019-08-06 19:15:18.801] nsd[4217]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 19:15:18 sulaco nsd[4217]: [2019-08-06 19:15:18.801] nsd[4217]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 19:15:18 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:18 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 3.
Aug  6 19:15:19 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 19:15:19 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 19:15:19 sulaco nsd[4220]: [2019-08-06 19:15:19.612] nsd[4220]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 19:15:19 sulaco nsd[4220]: [2019-08-06 19:15:19.612] nsd[4220]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:19 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 19:15:19 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 4.
Aug  6 19:15:19 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 19:15:19 sulaco systemd[1]: Starting Name Server Daemon...
Aug  6 19:15:20 sulaco nsd[4223]: [2019-08-06 19:15:20.200] nsd[4223]: error: could not open zone list /var/lib/nsd/zone.list: Permission denied
Aug  6 19:15:20 sulaco nsd[4223]: [2019-08-06 19:15:20.201] nsd[4223]: error: could not read zonelist file /var/lib/nsd/zone.list
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:20 sulaco systemd[1]: Failed to start Name Server Daemon.
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Service RestartSec=100ms expired, scheduling restart.
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Scheduled restart job, restart counter is at 5.
Aug  6 19:15:20 sulaco systemd[1]: Stopped Name Server Daemon.
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Start request repeated too quickly.
Aug  6 19:15:20 sulaco systemd[1]: nsd.service: Failed with result 'exit-code'.
Aug  6 19:15:20 sulaco systemd[1]: Failed to start Name Server Daemon.
So, how is sudo 'sudo /usr/sbin/nsd -d' different from 'sudo systemctl restart nsd.service' that would explain the above behaviour? How can I get NSD to start like normal using a systemd service, without it complaining it cannot read /var/lib/nsd/zone.list. It really has proper permissions, for crying out loud!:

Code: Select all

$ l -d /                      
drwxr-xr-x 23 root root 4.0K Aug  5 19:56 /
$ l -d /var
drwxr-xr-x 12 root root 4.0K Mar  1  2016 /var
$ l -d /var/lib
drwxr-xr-x 59 root root 4.0K Aug  5 20:38 /var/lib
$ l -d /var/lib/nsd
drwxr-xr-x 2 nsd nsd 4.0K Aug  6 19:02 /var/lib/nsd
$ l /var/lib/nsd/zone.list
-rw------- 1 nsd nsd 83 Oct 27  2016 /var/lib/nsd/zone.list
I can even verify the nsd user can read it, like so:

Code: Select all

$ sudo su -s /bin/bash nsd                       
nsd@sulaco:/home/pi$ ls /var/lib/nsd/zone.list
/var/lib/nsd/zone.list
nsd@sulaco:/home/pi$ cat /var/lib/nsd/zone.list
# NSD zone list
# name pattern
add bar.foo myzones
add foo.bar myzones
And still it doesn't work when launching it using systemd. :(

resill
Posts: 13
Joined: Fri Jun 12, 2015 8:55 pm

Re: Buster lies that files are on a read-only file system

Tue Aug 06, 2019 5:39 pm

bls wrote:
Tue Aug 06, 2019 5:02 pm
Oh, you didn't say you wanted to find and resolve the root problem...thought you just focused on getting nsd working. :o
Yes, perhaps that's my bad if I wasn't clear on this. Sorry.
There's obviously something dorked on your system from the upgrade process. As I've demonstrated, installing nsd on a fresh Buster works fine. This is one of the 7,436,294 reasons that I don't do upgrades. There are just too many things that can go wrong. It could also be something that you did to your pre-upgrade system that is causing this issue (been there, done that :oops: )

In fact, if you read https://www.raspberrypi.org/blog/buster ... -raspbian/, they said "We do not recommend upgrading an existing Stretch (or earlier) system to Buster – we can’t know what changes everyone has made to their system, and so have no idea what may break when you move to Buster."

Upgrading is always risky. Heck, I've been using Windows for an embarrasingly long time, and it's only with Win 10 that I stopped doing clean installs at every release and have embraced upgrades. Upgrades are hard for the system developers to get 100% right. There are too many things that they themselves do and forget to handle as part of the upgrade (thinking more about Windows here, but Linux has it's share of these). And let's not forget the unlimited things that we users do to our systems (both Windows and Linux). :lol:
I'm indeed tempted to start anew now, seeing these folks don't even recommend nor support upgrading to Buster. Thanks for mentioning.
One last suggestion, if you haven't tried it, is to apt-get remove nsd and then install it again. nsd seems to have been developed by folks who pay a lot of attention to details (geez, take a look at /lib/systemd/system/nsd.service :shock: ), so maybe reinstalling it will fix whatever is broken from the upgrade.
I tried this and it didn't work either.
Lastly, please change the name of this thread. A much more appropriate and useful title would be "nsd fails after Buster upgrade". It works fine on a clean install, and Buster isn't "lying" about read-only file systems.

Thanks
Fair enough - I just changed it.

bls
Posts: 2596
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: NSD fails after Buster upgrade

Tue Aug 06, 2019 5:56 pm

I don't know what the effect of all the settings in /lib/systemd/system/nsd.service are, but it seems a fair guess that one of those restricts nsd in a way that precludes it from running. Otherwise, there's very little, if any, difference between running nsd as root from the command line and systemd starting it.

If it were me, and I wanted to chase this down, I'd take the approach of commenting out all the lines in /lib/systemd/system/nsd.service between CapabilityBoundingSet=CAP_CHOWN CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_CHROOT
and ProtectSystem=strict (inclusive) as well as the last 2 lines (SystemCallArchitecture and SystemCallFilter).

If I'm correct, it should work. Then you can root cause it by trial and error, or by being lucky :lol:
Pi tools:
Quickly and easily build customized exactly as-you-want SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure IPSEC/IKEV2 VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

mno
Posts: 1
Joined: Wed Nov 27, 2019 10:44 am

Re: NSD fails after Buster upgrade

Wed Nov 27, 2019 11:01 am

Adding CAP_DAC_OVERRIDE as described in the bugreport below fixed it for me.

https://bugs.debian.org/cgi-bin/bugrepo ... bug=938987

Return to “Raspberry Pi OS”