Detecting read only file systen

You should make mediausers the group.
Like sonarr runs as sonarr:mediausers
And sabnzbd runs as sabnzbd:mediausers
New files they create automatically get owned by that group and thus permission is shared that way.
Of course both sonarr/sabnzbd users need to be member of the mediausers group, but I think you already set that up.
Note that process gid is not necessarily the same as the primary group of the user. The process uid/gid/umask determines the default ownership&permissions of new files created by that process.
If you’re using systemd to start sonarr/sabnzbd, then it’s easy to update the systemd unit with the uid/gid.

I don’t expect it to matter with our hardlink issue, but just advice to be able to set up permissions without needing acl.

You don’t have anything else special set up right? In sonarr systemd unit like hardening options?
Those would cause XROFS as well.
I still don’t know why link in mono behaves differently. I feel like we’re missing something here that’s causing the problem.

Yes I do actually. I thought I reverted them, but I didn’t. I was preparing for when systemd-analyze security hit my flavour of Ubuntu. Here’s my sonarr.service:

[Unit]
Description=Sonarr Daemon
Wants=network-online.target
After=network.target network-online.target

[Service]
User=sonarr
Group=sonarr
StandardOutput=null
Type=simple
ExecStart=/usr/bin/mono /opt/NzbDrone/NzbDrone.exe -nobrowser
TimeoutStopSec=20
KillMode=process
Restart=on-failure

# Sandboxing features
PrivateTmp=yes
NoNewPrivileges=true
ProtectSystem=strict
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
RestrictNamespaces=uts ipc pid user cgroup
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
PrivateDevices=yes
RestrictSUIDSGID=true
IPAddressAllow=192.168.0.0/24

[Install]
WantedBy=multi-user.target

After playing around with it, it’s the ProtectSystem=strict that results in those errors. The guide I used for the systemd hardening was https://github.com/alegrey91/systemd-service-hardening .

From the man page ProtectSystem:

           Takes a boolean argument or the special values "full" or
           "strict". If true, mounts the /usr and the boot loader
           directories (/boot and /efi) read-only for processes invoked by
           this unit. If set to "full", the /etc directory is mounted
           read-only, too. If set to "strict" the entire file system
           hierarchy is mounted read-only, except for the API file system
           subtrees /dev, /proc and /sys (protect these directories using
           PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=).
           This setting ensures that any modification of the vendor-supplied
           operating system (and optionally its configuration, and local
           mounts) is prohibited for the service. It is recommended to
           enable this setting for all long-running services, unless they
           are involved with system updates or need to modify the operating
           system in other ways. If this option is used, ReadWritePaths= may
           be used to exclude specific directories from being made
           read-only. This setting is implied if DynamicUser= is set. This
           setting cannot ensure protection in all cases. In general it has
           the same limitations as ReadOnlyPaths=, see below. Defaults to
           off.

Well, bingo :slight_smile:

If you have ProtectSystem=strict then you should set ReadWritePaths= appropriately to give it access to any directory you want sonarr to be able to write. That way you can maintain the added security.
I’m curious how it even works though coz I’d expect it to be unable to write to it’s own appdata directory… maybe home is excluded.
I don’t know what other effects there could be.

Play around with it. Please let me know if you have any issues remaining.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.