> FWIW all the systems I run that create pidfiles, either put them in
>
> /var/run
>
> or
>
> /tmpIf i use this directories the error turns to "Read-only file system".
I already thought, that the permission-error is not a "real" permission
thing, but a specific option in the service-file which is unlikely causing
the restriction.
...
while the output (systemctl status unbound) from the start via the
service-file is:===================================
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: creating udp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: creating udp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
error: cannot open pidfile /test/unbound/unbound.pid: Permission denied
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0]
debug: chdir to /test/unboundI shall look what exactly each of the options in the service-file means...
You have lot of sandboxing options(Protect*, Restrict* etc.) in the
unbound.service file.
For example ProtectSystem=strict
(https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=)
Have you tried commenting all Protect*, Restrict* etc. and see if unbound is
then able to start (and write to /test/unbound) ? And after that start
adding those sandboxing options one by one ?
-Jarno