Synology DSM 7.1: Permissions broken as of 3.6.0?

[meimeiriver]

SABNZBD broke on my DSM 7.1 NAS, as of 3.6.0. All files are now set for:

sc-sabnzbd synocommunity

With only rw permissions. Allegedly for security reasons. Have to say I'm pretty annpyed by this. Has it ever occured to anyone, that people want to make the downloads/ folder a SMB share, so data can be retrieved/deleted from it? With only the (internal) sc-sabnzbd user having access to the folders, Can't even add a user to the synocommunity group any more (for one, because the group is no longer given access even).

So, how can I give another user access the download folders??

EDIT:

Now see, this makes no sense:

drwxrwxrwx+ 1 sc-sabnzbd synocommunity 138 Jun 20 15:07 604bc5892df75836e84cbe17
drwx------ 1 sc-sabnzbd synocommunity 384 Jun 20 15:10 604bc5892df75836e84cbe18

2 folders, written right after each other, and sabnzbd choses to make 1 inaccesible to all but the sabnzbd user, the other not.

[safihre]

Did you change the Folder Permissions setting in SABnzbd? It should be empty.
All permission management should be done in DSM, not in SABnzbd, because the "Linux" permissions used by SABnzbd break the ACL permissions used by DSM.
You should indeed arrange things using the groups and users of DSM.
For more information, check SynoCommunity.
https://github.com/SynoCommunity/spksrc ... plications

[meimeiriver]

Thx for your reply. Had done all these things already (was working fine up to 3.5), but something seems broken. Look at the example above (in the downloads folder):

drwxrwxrwx+ 1 sc-sabnzbd synocommunity 138 Jun 20 15:07 604bc5892df75836e84cbe17
drwx------ 1 sc-sabnzbd synocommunity 384 Jun 20 15:10 604bc5892df75836e84cbe18

The first one created by sabnzbd, inherits 777 permissions properly (not ideal, bit sabnzd has hard coded access to only an internal user, without ability to change that). For the second one, however, created 3 minutes later, sabnzbd decided to lock access to all but the internal user again.

Sometimes sabnzbd created the downloaded folder with 777, but then the files therein again as rw only for the sc-sabnzbd user.

[safihre]

We haven't hard-coded anything. This is what is done by DSM.
You can enable Debug logging in the Status window and then check the logs after it happens again, it will show exactly which permissions were applied by SABnzbd. The rest is all done by DSM/filesystem.

[meimeiriver]

We haven't hard-coded anything. This is what is done by DSM.
You can enable Debug logging in the Status window and then check the logs after it happens again, it will show exactly which permissions were applied by SABnzbd. The rest is all done by DSM/filesystem.

I appreciate your help But it's all very strange. Look at this download folder again, please:

Code: Select all

d---------+ 1 root       root           58 Jun 21 02:01  ..
drwxrwxrwx+ 1 sc-sabnzbd synocommunity 100 Jun 21 08:43 'test download'

drwxrwxrwx+ 1 sc-sabnzbd synocommunity 100 Jun 21 08:43 .
drwxrwxrwx+ 1 sc-sabnzbd synocommunity  80 Jun 21 08:43 ..
drwx------  1 sc-sabnzbd synocommunity  90 Jun 21 08:43 testfolder

'test download' gets 777. but 'testfolder' therein gets created with 700 again. Like 1 out of 2 downloads gets borked, this way. And I made sure my user made for SMB access has full, recursive perms applied to download, and all subfolders (all via DSM). In fact, I completely uninstalled SABNZBD (full erase), then reinstalled it again. Same effect.

The log just said 'permissions=' (blank). So, no extra permissions appear to be appied. Is there a setting for these permissions somewhere? I used my old 3.5 config.ini, btw.

[meimeiriver]

We haven't hard-coded anything. This is what is done by DSM.

I found a (heretofore) blank setting in config,ini, to set final permissions on the 'complete' folder, I set those to 777. That seems to do it. Albeit ugly. And shouldn't be necessary. But with half my downloads now getting rw only for the sc-sabnzbd user, seems like the only 'solution'.

[safihre]

Every update of the SynoCommunity package, permissions-settings will be emptied again. This is done on purpose (not by SABnzbd, but by SynoCommunity package!) because like I said before, the Linux permissions of SABnzbd break the ACL permissions of Synology.
For example: if SABnzbd applies it's Linux permissions, Sonarr (after being added to the same group in DSM) for example can't access the files anymore.

In the logs (only after enabling Debug logging) you will see "Applying permissions X (octal) to Y", you could investigate those.

[meimeiriver]

Every update of the SynoCommunity package, permissions-settings will be emptied again. This is done on purpose (not by SABnzbd, but by SynoCommunity package!) because like I said before, the Linux permissions of SABnzbd break the ACL permissions of Synology.
For example: if SABnzbd applies it's Linux permissions, Sonarr (after being added to the same group in DSM) for example can't access the files anymore.

In the logs (only after enabling Debug logging) you will see "Applying permissions X (octal) to Y", you could investigate those.

Thx for the explanation. I don't need Sonarr; other than that, does it hurt anything when I let sabnzd set 777 on the 'complete' folder? For one, I don't know of another way to solve the 'rw to sc-sabnzbd user only' issue. The permission inheritence from parent folders apparently only works half of the time, and there's no normal, safe UNIX way (like adding my SMB user to the synocommunity group; and even if I could, DSM 7.1 would ignore it).

I really think the SynoCommunity ought to rethink the whole deal. Making sc-sabnzbd an internal user is one thing. But then breaking normal UNIX group access (especially for shares) is weird. And sc-sabnzbd is not a user you can log in with (via SMB). Then forcing rw for sc-sabnzbd:synocommunity only misses the mark entirely, as there's not even UNIX group access possible, so you have to resort to letting sabnzbd do a chmod 777 on the 'complete' directory, in order to give anyone else access to the output folders. None of which would be needed if permission inheritance worked properly: on one download it works, the other it doesn't and reverts to rw for sc-sabnbd user only (despite the per-folder rw permissions I gave to my SMB user) for the entire tree.

Anyway, not your fault. And I appreciate the help you gave me. 777 it is, then. Fortunately, the 'complete' folder is a low-security for me: just a 'transport' folder, basically, to move stuff to and from my PC.

[safihre]

It's not the choice of SynoCommunity, it's Synology that forces this way to working starting with DSM 7. They introduced this internal users in an effort to prevent packages to have full access to your whole NAS.
Same for the Linux permissions, it's Synology that forces this.
Trust me, they hate it just as much as you

But indeed, if you only use SMB then this will work. Just know that it will be reset after every update of the package.