As an example, the redis-server.service has the following directives (I have elided the irrelevant ones):
ReadOnlyDirectories=/
ReadWriteDirectories=-/opt/data/redis
ProtectSystem=true
This correctly makes /opt/data/redis writable for the service outside LXC.
However, in LXC the zzz-lxc-service.conf drop-in clears ReadWritePaths=. As a consequence /opt/data/redis is now subject to ReadOnlyDirectories=/, hence not writable.
This appears to be the inverse of what the drop-in is intended to do. Whereas it overrides all Protect* directives, thus defaulting to writable paths, it clears (i.e. makes read-only) the paths that the service explicitly needs to be writable.
Changing line 109 in lxc.generator to:
[ "${SYSTEMD}" -ge 231 ] && echo "ReadWritePaths=" && echo "ReadOnlyPaths=";
... fixes the issue, but:
[ "${SYSTEMD}" -ge 231 ] && echo "ReadOnlyPaths=";
... is perhaps closer to the actual intention?
Cheers
Marco
As an example, the
redis-server.servicehas the following directives (I have elided the irrelevant ones):This correctly makes
/opt/data/rediswritable for the service outside LXC.However, in LXC the
zzz-lxc-service.confdrop-in clearsReadWritePaths=. As a consequence/opt/data/redisis now subject toReadOnlyDirectories=/, hence not writable.This appears to be the inverse of what the drop-in is intended to do. Whereas it overrides all
Protect*directives, thus defaulting to writable paths, it clears (i.e. makes read-only) the paths that the service explicitly needs to be writable.Changing line 109 in lxc.generator to:
... fixes the issue, but:
... is perhaps closer to the actual intention?
Cheers
Marco