SABnzbd seems to be installed with a missing/incorrect "permissions" setting

[ludovicchabant]

Setup

Package Name: SABnzbd Package Version: 3.3.1-49

NAS Model: DS918+ NAS Architecture: apollolake (x64) DSM version: 7.0-41890

Expected behavior

SABnzbd should create its "completed" downloads folders and files with the correct permissions by default, so other programs such as Sonarr or Radarr can pick those downloads up and rename/move/whatever.

Actual behavior

SABnzbd is instead creating these "completed" downloads folders and files with restrictive permissions. This was reported on the SABnzbd forums, where Safihre said that the Synology package should default to 0777 for these permissions. It looks like it's not the case. A simple workaround is to go in SABnzbd's settings and force it to 0777 but it shouldn't be necessary.

Forum thread: https://forums.sabnzbd.org/viewtopic.php?p=125635&sid=2eb52c025749edbe5bfc5be5718f03bf#p125635

SynoCommunity package config: https://github.com/SynoCommunity/spksrc/blob/master/spk/sabnzbd/src/config.ini#L3

Steps to reproduce

1. Install SBnzbd 2. Make it download something 3. Check the permissions on the downloaded folder and files

Package log

Nothing in there (just the exec command for the process)

Other logs

N/A

[BenjV]

Please read the wiki about this subject!

You have to give the "system internal user" from the packages you want to give access to those folders the correct permissions yourself via the control panel, shared folders, select folder, click permissions, select "System internal users" and give the sc-radarr and sc-nzbdrone users the correct permission on SabNzbd share.

As of DSM 7 this cannot be done by the installation scripts of packages. And defaulting to 0777 would a security risc and also useless, because Synology uses extended files permissions (also known as ACL's).

[ludovicchabant]

You have to give the "system internal user" from the packages you want to give access to those folders the correct permissions yourself

Yep, I had done that, but somehow it doesn't stick to folders created inside it. So for example I can check that SABnzbd's root share has R/W permissions for all the relevant system internal users, and that the directories inside also have them. But any directory created by SABnzbd inside the complete directory for newly completed downloads do not have these permissions -- instead, they just have R/W by the sc-sabnzbd user, and read-only permissions for "Everyone". Well, actually even the sc-sabnzbd user doesn't have full R/W: somehow it doesn't have the "delete" permissions.... which is weird.

Am I possibly missing some setting on the share to set the default ACLs on new directories and files?

[BenjV]

Of course there is no write permission for everyone that would be a gross security risk. There is a setting in SABnzb (Permissions for completed downloads) to change that, but everyone is of course a bad idea.

A better Idea would be to create a group and give that group write permissions in the SabNzb setting. Then you could add users who need write permissions to that group. If you do so don't forget to also add that group to the root share of SabNzbd.

And Linux does not have a delete permission, only read, write and execute.

[ludovicchabant]

There is a setting in SABnzb (Permissions for completed downloads) to change that, but everyone is of course a bad idea. A better Idea would be to create a group and give that group write permissions in the SabNzb setting.

Yes, that's the setting I changed. I could indeed put both the SABnzbd and Sonarr/Radarr/etc users in a common group, and set that setting to 0775... but I don't think we can do that via DSM? (I can't find a way) We would need to go fiddle with DSM's internal users directly via SSH, no? For me, the sc-sabnzbd user is actually alone in a sc-sabnzbd group.

Note that the SABnzbd directories (the share root and the complete directory inside it) have restricted rights to read and execute inside them to begin with. So even if the completed directories are created with 0777, it would be limited to whoever can pass through the first levels, I think?

Anyway my point here is that, unless there's something unusual about my box somehow, SABnzbd doesn't work as expected when installed, even after following the instructions on the wiki. I'm good with either amending the wiki instructions or fixing the installation scripts or both.... and if some people report that it worked OK out of the box for them, I'd love to hear about it and see what's different with my setup.

[ludovicchabant]

Digging a bit further into my setup, I wonder if the installation of SABnzbd missed adding its service user to some groups. My sc-radarr and sc-nzbdrone users both belong to sc-download and sc-media, in addition to their own private group. But like I said, sc-sabnzbd only belongs to its own group.

Surely it should have been added to the download and media groups? It looks like it's doing it only for DSM6 and below. Why?

[BenjV]

As of DSM 7 it is no longer possible to add users to a group by the installation scripts. That's why the group solution has to be abandoned. This is because Synology decided that the installation script are no longer running as root but (in this case) just as sc-sabnzbd and without sufficient permission you cannot create groups nor add members.

You clearly did not follow (or understand) the directives of the wiki. The way to go is give the "system internal user" of the application who must access the file read/write permissions. When you use folders that exists before installing sabnzbd you should also set this permissions to the existing folders and files recursively, you can do that with FileStation.

Some people reported problem in doing so but I could not reproduce that, so if it gives problems it would be advised to use folders that are created by the sabnzbd installation and not use existing folders.

[ludovicchabant]

Thanks for the info. AFAICT I followed the wiki correctly but I'll start from the beginning, with as much detail as I can provide, in case I missed something.

1. Sonarr and Radarr were already installed before my upgrade to DSM7.
2. I installed SABnzbd after upgrading to DSM7.
3. There were no existing directories for SABnzbd. IIRC I created a new share at that moment, to point the installation wizard to it. The installation script created the watch, complete, and incomplete directories itself.
4. The wizard pointed me to this wiki page. I went with Option 1, giving the SABnzbd share R&W permission to sc-nzbdrone and sc-radarr, and "Full Control" to sc-sabnzbd.
5. The rest of the wiki page is for Option 2, or for Troubleshooting, so I ignored it and went back to the installation.
6. Installation finished without problem and after some basic config, SABnzbd started chugging along nicely.

However, after running into permission problems, I observed the following:

1. I checked that the SABnzbd share still had R&W permission to Radarr/Sonarr service users, and "Full Control" to SABnzbd service user.
2. I checked that the complete directory still had R&W permission to Radarr/Sonarr service users, and "Full Control" to SABnzbd service user.
3. I checked the directories created by SABnzbd inside the complete directory, and those had strange different permissions: "Custom" for the sc-sabnzbd group (R&W without "Delete"), "Read" permission for the sc-sabnzbd user, and "Read" permission for "Everyone". This was obviously wrong so I went to check SABnzbd's settings.
4. The "Permissions for Completed Downloads" setting in SABnzbd was empty. I don't know if the package default config got applied? It seems to set it to 0777? So I set it myself to 0777, and that fixed it.

I hope this helps.

[pittsjl]

I'm having similar problems. I currently have the following user/group/permissions scheme setup for the downloads and media folder trees:

administrator@NAS01:~$ cat /etc/group | grep "sc-download\|synocommunity"
sc-download:x:65536:admin,administrator,sc-nzbdrone,sc-radarr,sc-lidarr,sc-sabnzbd,emby
synocommunity:x:207066:

All of the associated sc-* local system users as well as the sc-download group have Full Control of all folders.

After experimenting with "Permissions for Completed Downloads" set at 777, I noticed when SABnzbd moves the file from the incomplete download folder to the category folder where Sonarr/Radarr/Lidarr/etc. watch for the file, SABnzbd creates those folders with these users/groups and permissions:

User - sc-sabnzbd - Custom (Administration/None, Read/All, Write/All (Delete unchecked))
Group - synocommunity - Custom (Administration/None, Read/All, Write/All (Delete unchecked))
Group - Everyone - Custom (Administration/None, Read/All, Write/All (Delete unchecked))

Presumably SABnzbd should be creating folders using the sc-download group instead of the synocommunity group? I don't have any of the local system users for the other applications added to that group since the installation instructions still instruct to use the sc-download group.

I reckon I could use 775 permissions if the correct group was assigned to the folder when created. Or do I need to assign all the local system users to the synocommunity group instead?

Also curious if Delete is unchecked whether SABnzbd can even delete the file if Sonarr, etc. instructs it to do so, or if Sonarr, etc. can move the file to the final destination media folder (if a Move is treated like a Copy + Delete).

[BenjV]

My advice would be, don't try to mess with permission setting by SabNzb and/or other applications themselves, those application don't understand the DSM permission system.

The problem is that Synology switched to extended permissions also known as ACL's and if you are changing things to standard permissions outside the DSM gui, you mess thing up badly. The installations script uses DSM to create the folders and set the ACL permissions and you should only add the "system internal users" of other application via the DSM gui.

@pittsjl I already explained why the sc-download group cannot be used anymore as of DSM 7, so I suggest you read that.

[ludovicchabant]

As you can see from my steps, I didn't mess with permissions outside of DSM's interface, and outside of what the wiki told me to do.

I'm curious to know why you think 0777 permissions on completed downloads is wrong when it seems to be what the package's default config is trying to do? Or is that something else?

[BenjV]

The package does not do that, it creates ACL permissions and if you set things to 0777 you revoke the ACL and the DSM permission won't work correctly anymore? Your confuse the package with the application.

I am not sure if Sabnzbd tries to set old style permissions, but if does that will mess-up the ACL's that DSM is using. It should just create files and folder without setting permissions, then the permissions will be inherited from its parent (including the ACL).

[ludovicchabant]

Your confuse the package with the application.

What I meant was that the package has this config.ini file with permissions = 777 in it, so it seems to me like it's meant to set that as the default config for a newly installed application, no? (possibly as a workaround for SABnzbd's use of old-style permissions) So either (1) this default configuration is not correctly installed (it's a package bug) or (2) this default configuration is unused and could be deleted (it's a red herring).

I am not sure if Sabnzbd tries to set old style permissions, but if does that will mess-up the ACL's that DSM is using.

Ah, we're making progress. I took a look at SABnzbd's code and it looks like it always tries to set old-style permissions indeed, even when the permissions config is empty. I'll file an issue with that project.

[Safihre]

From SABnzbd 3.5.0 it will no longer force old-style permissions.

[mreid-tt]

From SABnzbd 3.5.0 it will no longer force old-style permissions.

hey @Safihre, I'm not sure this is actually working as expected given my recent experience comparing my deployment with a fresh installation of SABnzbd 3.7.1. See some experimentation I did: https://github.com/SynoCommunity/spksrc/issues/5140#issuecomment-1368469972. I find it still sometimes forces downloaded files (not folders) to have explicit permissions rather than simply inherit from the parent.

[Safihre]

Yes, if the files have X bits from within the archive we will forcefully remove them to prevent malicious attackers from abusing an exposed SABnzbd.

[mreid-tt]

Yes, if the files have X bits from within the archive we will forcefully remove them to prevent malicious attackers from abusing an exposed SABnzbd.

Okay, this makes sense but depending on which are forcibly removed I've seen some files extracted with custom permissions for only 'sc-sabnzbd' and 'synocommunity' (no Everyone) but with others I only see custom permissions for 'sc-sabnzbd' only. In that instance without the 'synocommunity' group present, the files are unable to be processed by *arr apps. To fix it, I would go to my downloads folder and right-click on the downloaded folder for the properties and then click the checkbox for 'Apply to this folder, sub-folders and files' under the 'Permission' section. Once that was done, the files could be processed as normal.

Would there be perhaps a way to only strip the bits for the 'Everyone' layer if present but leave the group in tact (or manually set it)? I can't say I fully understand the ACL stuff but would that be a good middle-ground from a security perspective?

[Safihre]

That's exactly what we do, we only mask out those bits. Not sure what happens after that due to DSM and ACL. On other Linux systems this works exactly as designed. You can enable Debug logging in the Status window and then after it happens again check the logs for what permissions were applied.

[mreid-tt]

Hmm, okay, so I set the logs to debug mode and downloaded a small music album. The logs are found here: https://pastebin.com/0xjPspP7. In this example the files extracted looked like this:

Of course, Lidarr could not process them with these permissions and threw errors. Looking at the debug log these lines seem to be relevant:

2023-01-02 14:39:50,069::DEBUG::[filesystem:604] Applying permissions 0o100666 (octal) to /volume1/downloads/incomplete/Rihanna Loud/Rihanna - Loud.nfo
2023-01-02 14:39:50,075::DEBUG::[filesystem:604] Applying permissions 0o100666 (octal) to /volume1/downloads/incomplete/Rihanna Loud/Rihanna Loud .vol-01.par2
2023-01-02 14:39:55,286::DEBUG::[filesystem:604] Applying permissions 0o100666 (octal) to /volume1/downloads/incomplete/Rihanna Loud/Rihanna - Loud.part1.rar
2023-01-02 14:40:00,384::DEBUG::[filesystem:604] Applying permissions 0o100666 (octal) to /volume1/downloads/incomplete/Rihanna Loud/Rihanna - Loud.part2.rar
2023-01-02 14:40:02,664::DEBUG::[filesystem:604] Applying permissions 0o100666 (octal) to /volume1/downloads/incomplete/Rihanna Loud/Rihanna - Loud.part3.rar

Let me know what you think. Is it behaving differently than with other Linux systems?

[BenjV]

The only way to set permissions on DSM 7 is to give the "System internal user" sc-sabnzbd the correct permissions on the used share. And if you have exsisting folders and files on that share you can give that user permissions with File Station via the properties.

Any attempt to use the old style permissions will not work because DSM uses the Linux extended permission system (ACL+)

[mreid-tt]

I'm not sure I get your meaning @BenjV. The permissions are correct for the used share per the FAQ on this. The concern is that extracted files from archives sometimes have their permissions set to values which differ from what they would normally inherit. This difference sometimes results in only having permissions for 'sc-sabnzbd' (as seen above) which results in other *arr apps not being able to post-process the downloads (despite these apps having explicit permissions for the underlying share).

When you mention that setting old style permissions "will not work", do you mean that their resultant values will not be as expected? Setting old style permissions with a command like chmod should execute normally, shouldn't it? If I am completely misunderstanding you, can you direct me to resources to better understand?

[BenjV]

When an application like SABnzbd downloads a file and put it on a share folder then the "system internal user" of SabNzbd (sc-sabnzbd) needs permission on that share. The only way to give sc-sabnzbd that permission is via the control panel (shared folders). That way DSM wil set ACL+ permissions on that share so sc-sabnzbd can access files on that share.

When the applicatie (Sabnzbd) change the permission with "old style" Linux permission then things get messed up and stop working the way it should, because the ACL+ is removed en other "system internal users" cannot access those files anymore.

For example when Sabnzbd uses torrents it needs a torrent downloader like for example transmission. Then you have to give their "system internal user" (sc-sabnzbd and sc-transmission) permission on the share where transmission puts the files it downloads. When transmission would change the permission on that file to an "old style" permission then only transmission (the owner) can access that file because Sabnzbd does not have permissions anymore.

The same would happen if Sabnzbd would change the permission of video files, other application would not be able to access them anymore via the standard way. The system internal users are special users with their own uuid range and DSM keeps track of them in its own database.

If something like unzip or unrar is used with an option to keep the existing permission things also get messed up, because you don't know what that permissions are and you cannot change without messing up the DSM permission system database. The only advise I could give is to extract files leaving the permissions behind (it is never a good idea to add permissions from another system).

As a workaround when you have files without the correct permission, you could use FileStation to add permissions. Go with FileStation to the file (or subfolder) select it, right click it and choose properties, then permissions and tick read/write permission and select the correct system internal user.

Until now it is not clear what DSM is exactly doing with the permission system, but this is what I found out about it. Don't mess with it and only use the DSM gui to change them.

[mreid-tt]

That's exactly what we do, we only mask out those bits. Not sure what happens after that due to DSM and ACL. On other Linux systems this works exactly as designed. You can enable Debug logging in the Status window and then after it happens again check the logs for what permissions were applied.

hey @Safihre, I've done some further investigation into this and I believe I have a fix which should work and I've included as PR https://github.com/sabnzbd/sabnzbd/pull/2401.

[ludovicchabant]

See some experimentation I did

Oh interesting, thanks @mreid-tt -- I have been fighting the return of these permission bugs lately, and realized that, indeed, my complete directory has the correct permissions, but my incomplete directory had the wrong ones. I fixed that... we'll see if it gets better.

Also, to be clear, on DSM7, we should have an empty "Permissions for completed downloads" setting, correct? (i.e. Sabnzbd shouldn't set anything?)

[mreid-tt]

Also, to be clear, on DSM7, we should have an empty "Permissions for completed downloads" setting, correct? (i.e. Sabnzbd shouldn't set anything?)

The PR that I made to look into this is evolving to have a more permanent fix. At the moment I would recommend leaving it set to '777'. At the moment leaving it blank works most of the time but there are some instances where there are still some permissions issues.

[BenjV]

Not a good idea to set it to '777', leave it blank so you follow the DSM settings is the better option. If there are issue with that setting, it stems for incorrect settings in DSM or old settings from within applications and should be fixed in DSM. Besides application don't have any privileges to do that if they file is not owned by the application or the application has no traverse rights on the folder.

[mreid-tt]

New version of SABnzbd has been published which incorporates the fix for this issue.