Run sabnzbd as specific user:group [Debian]

[Lustily4025]

Hello!

I have setup sabnzbd on a few containers/vms recently but this last one is causing me issues. I am running 4.3.2 on the latest Debian and need the service to run as a specific user:group. However, when I start it, it runs as user:user, which causes issues with folder permissions for other applications. I have edited etc/default/sabnzbdplus with USER=user:group and have verified that the user (my account) and group is listed on the system.

The previous version I was running was 4.2.3, which had the same settings and worked. The service now runs as [email protected] and that is different than on 4.2.3. Something must have changed in the update(s).

Thank you for any assistance!

[sander]

? maybe related to https://github.com/sabnzbd/sabnzbd/comm ... 279f2675ac ?

so: does 4.3.1 run OK for you?

[jcfp]

However, when I start it, it runs as user:user, which causes issues with folder permissions for other applications. I have edited etc/default/sabnzbdplus with USER=user:group and have verified that the user (my account) and group is listed on the system.

The previous version I was running was 4.2.3, which had the same settings and worked. The service now runs as [email protected] and that is different than on 4.2.3. Something must have changed in the update(s).

It did indeed: a native systemd service was added, as the init.d compatibility layer we relied upon to mostly avoid systemd until now has been deprecated. The init.d script is still installed with the package for anyone truly allergic to systemd, and the new systemd service parses the same old settings file in /etc/default which should make this switch go unnoticed for 99.9% of users.

The sole feature that wouldn't carry over is the hidden but long supported option of using the USER variable to set a user:group combo. Systemd apparently - documentation isn't their forte either - lacks support for taking a service's user and group from variables beyond their so-called "specifier" (the %I in the service definition), so mechanisms such as ExecStartPre cannot be used for this purpose. After parsing the service settings file both user and group are known, but we're left with no decent way to actually set the group.

As a workaround, you could try using an override to set the group via:

Code: Select all

systemctl edit [email protected]

...then add a (hardcoded) Group=woteva on a line of its own in the same section as the User=%I line. Haven't tested that though, so feedback is highly appreciated.

As always, hints for improvements are welcome; the relevant files are installed as:
/lib/systemd/system/sabnzbdplus.service
/lib/systemd/system/[email protected]

For now, the new systemd stuff is only shipped in Debian unstable/testing (and backports/derivatives thereof), as well as on the Ubuntu PPA for 24.10/oracular.

[Lustily4025]

I tried your suggestion of

Code: Select all

systemctl edit [email protected]

but it gave me an error when I saved it (my knowledge at this level is pretty low). However, I edited

Code: Select all

/lib/systemd/system/[email protected]

and added a line with Group=name. I have no downloads pending, so I tried exporting a backup, which had the correct permissions.

I will continue to monitor this and see if it works.

Thank you for your assistance!!

[jcfp]

but it gave me an error when I saved it

Probably needs 'sudo' in front, the override file is stored somewhere in /etc iirc.

Direct edits to /lib/systemd/system/[email protected] will also work, but probably get overwritten whenever the sabnzbdplus package receives updates.

[Lustily4025]

I definitely used sudo to edit the service, the issue is, it wants to save a file called

Code: Select all

.#override.conf1fc616b1d84007dd

After changing the file to override.conf and a lot of searching online, I was able to get it updated. In case anyone else searches for this topic and gets this thread, I had to add

Code: Select all

[Service]
Group=
Group=media

Between the comments. It finally seems to work. Clearing the old group before setting a new group was the final missing piece. Good thing someone else already had this issue on askubuntu[dot]com! I removed any changes to the file in /lib/systemd/system/[email protected] so I would not have to worry about an update reverting it.

Thank you for your assistance and I hope this works!