Permissions gone since Sonarr/Transmission update

[WolfH]

For new Package Requests, see the guidelines

Setup

Package Name: Sonarr / Transmission Package Version: Latest update

NAS Model: DS214 NAS Architecture: ARM DSM version: DSM 6.1.5-15254 Update 1

Expected behavior

Sonarr should be able to move items from the Transmission download-folder to the media-folder as it did before the update.

Actual behavior

It seems that permissions for Sonarr have been set wrong since updating to the newest version using the sc-download group. I'm getting errors like:

Couldn't import episode /volume1/homes/admin/downloads/NAME.mkv: Access to the path is denied.

I've checked the permissions in File Station and the downloads folder is owned by user sc-transmission and group sc-download (to which sonarr belongs if I'm not mistaken).

It worked fine before, this all started since updating to the new permissions-structure.

Steps to reproduce

1. Install the latest update. 2. Try to download and move a file.

[Safihre]

How are you with SSH? We need to identify where this is going wrong. Maybe you can also help @SX86? If you SSH into the device, can you post the output of each folder in the path up to the file of:

ls -al /volume1/
sudo synoacltool -get "/volume1/" 

And then also for any of the folders up to the file's folder?

[WolfH]

I'm not super with SSH, but here goes nothing. I mentioned the wrong folder above, it's the bittorrent folder.

admin@TheTARDIS:~$ ls -al /volume1
total 10956
drwxr-xr-x  16 root  root       4096 Feb 28 08:26 .
drwxr-xr-x  21 root  root       4096 Feb 28 08:26 ..
drwxr-xr-x  19 root  root       4096 Mar  2 07:59 @appstore
-rw-------   1 root  root      14336 Feb  6 08:17 aquota.group
-rw-------   1 root  root      15360 Feb  6 08:17 aquota.user
drwx------   2 root  root       4096 Feb  6 08:12 @autoupdate
drwxr-xr-x   5 admin users      4096 Feb 27  2017 @database
drwxr-xr-x   2 admin users      4096 Oct 14  2013 @download
drwxrwxrwx+  4 root  users      4096 May 12  2015 @eaDir
-rw-------   1 root  root   10395648 Jun 14  2014 @heartbeatd.core
drwxrwxrwx+  8 root  root       4096 Apr 27  2016 homes
drwx------   3 root  root       4096 May  2  2017 @iSCSI
drwx------   2 root  root      16384 Oct 14  2013 lost+found
-rw-------   1 root  root     258048 Jan  8  2017 @mono.core
-rw-r--r--   1 root  root       2048 Nov 21  2013 .quarantine
drwxr-xr-x   3 root  root       4096 Nov 21  2013 @quarantine
drwxr-xr-x   2 root  root       4096 Nov  7  2014 @S2S
drwxrwxrwx   4 root  root       4096 Sep 10  2014 @spool
-rw-------   1 root  root  138031104 Jul  8  2017 @synoelasticd.core
-rw-------   1 root  root   11952128 Jan  8  2017 @synopkg.core
-rw-------   1 root  root       5120 Mar 23  2016 synoquota.db
drwxrwxrwx   5 root  root       4096 Mar  2 08:56 Backups
drwxrwxrwt  14 root  root       4096 Mar  2 08:57 @tmp
drwxr-xr-x   4 root  root       4096 Feb 27  2017 @USBCopy
-rw-r--r--   1 root  root      28672 Jun  7  2015 winbindd_cache.tdb

admin@TheTARDIS:~$ sudo synoacltool -get "/volume1/" `
(synoacltool.c, 359)It's Linux mode

admin@TheTARDIS:~$ ls -al /volume1/homes
total 76
drwxrwxrwx+  8 root             root  4096 Apr 27  2016 .
drwxr-xr-x  16 root             root  4096 Feb 28 08:26 ..
drwxrwxrwx+  8 admin            users 4096 Feb 28 22:09 admin
-rw-rw-rw-   1 admin            users  291 Oct 24  2013 .apdisk
-rw-rw-rw-   1 admin            users 6148 Jul  7  2016 .DS_Store
drwxrwxrwx+  3 root             users 4096 Feb  6 08:19 @eaDir
drwxr-xr-x   6 User1 users 4096 Sep 20 12:58 User1
drwxrwxrwx+  2 root             root  4096 Aug 11  2015 #recycle
drwxrwsrwt   4 admin            users 4096 Jul 15  2014 .TemporaryItems
drwxr-xr-x   2 backups      users 4096 Apr 27  2016 backups

admin@TheTARDIS:~$ sudo synoacltool -get "/volume1/homes/" 
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [root(user)] 
--------------------- 
     [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:0)
     [1] group:sc-download:allow:--x----------:---n  (level:0)

admin@TheTARDIS:~$ ls -al /volume1/homes/admin/
total 1056
drwxrwxrwx+ 8 admin           users         4096 Feb 28 22:09 .
drwxrwxrwx+ 8 root            root          4096 Apr 27  2016 ..
-rw-rw-rw-  1 admin           users          290 Oct 22  2013 .apdisk
drwxrwx---  7 sc-transmission sc-download  36864 Mar  2 08:29 bittorrent
drwxrwx---  6 admin           sc-download   4096 Nov  3  2013 downloads
-rw-rw-rw-  1 admin           users         6148 Dec 27 22:44 .DS_Store
drwxrwxrwx+ 2 root            users         4096 Feb 28 22:09 @eaDir
drwxrwsrwx  7 admin           users         4096 May  6  2017 iTunes
drwxrwxrwx  6 admin           sc-download   4096 Apr 14  2015 Media
drwxrwxrwx  3 root            root          4096 Mar 26  2016 Reports
-rw-------  1 admin           users         1379 Dec 27 21:07 .viminfo
-rw-rw-rw-  1 admin           users       951739 Oct 27  2013 .VolumeIcon.icns

admin@TheTARDIS:~$ sudo synoacltool -get "/volume1/homes/admin/" 
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [admin(user)] 
--------------------- 
     [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:0)
     [1] group:sc-download:allow:--x----------:---n  (level:0)

admin@TheTARDIS:~$ ls -al /volume1/homes/admin/bittorrent/
total 14715760
drwxrwx---  7 admin           sc-download       36864 Mar  2 08:29 .
drwxrwxrwx+ 8 admin           users              4096 Feb 28 22:09 ..
-rwxrwxrwx  1 admin           sc-download        6148 Aug 27  2017 .DS_Store
drwxrwxrwx+ 2 sc-transmission transmission      12288 Mar  2 08:19 @eaDir
and a whole list of files

admin@TheTARDIS:~$ sudo synoacltool -get "/volume1/homes/admin/bittorrent/" 
(synoacltool.c, 359)It's Linux mode

[Safihre]

Could you try once more to set/add sc-download to /volume1/homes/admin/bittorent? Seems something set Linux permissions on that folder and the files in there are owned by transmission.

[elisimpson]

After uninstalling old version and installing new Transmission I'm seeing the user set to "sc-transmission" and group to "transmission"... is this right? I thought the group was supposed to set to "sc-download"

[Safihre]

The sc-transmission is a member of sc-download so they share the same access.

[SX86]

@Safihre I can help, for sure! Not sure how posting the listing of volume1 will help though, so I will only post what matters to me in this case, the download folder.

Like @elisimpson said, I was expecting the new downloads from Transmissions to be owned by user:group sc-transmission:sc-download and not sc-transmission:transmission.

Here's some of the info you requested:

ash-4.3# sudo synoacltool -get "/volume1/"
(synoacltool.c, 359)It's Linux mode

ash-4.3# sudo synoacltool -get "/volume1/download"
ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [root(user)]
---------------------
         [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:0)
         [1] group:sc-download:allow:--x----------:---n  (level:0)

ash-4.3# ls -al /volume1/download/
total 40
d---------+  7 root            root         4096 Mar  2 10:15 .
drwxr-xr-x  29 root            root         4096 Feb 27 10:15 ..
drwxrwxrwx   7 sc-transmission sc-download  4096 Mar  1 10:09 Downloads
drwxrwxrwx+  3 root            root         4096 Feb 19 16:46 @eaDir
drwxrwxrwx   2 sc-transmission sc-download 12288 Mar  2 04:45 Incomplete
-rwxrwxrwx   1 Franck          users           0 Dec 10  2015 .nomedia
-rwxrwxrwx   1 Franck          users        2325 Dec 17 20:22 SonarrCleanUpScript.ps1
drwxrwxrwx   4 sc-transmission sc-download  4096 Mar  1 10:03 Torrents
drwxrwxrwx   3 Franck          users        4096 Nov 16  2016 Transmission Remote GUI Settings

"Downloads" is my default download location for Transmission. I manually set the permissions on it yesterday. But, here's the attributes of a folder that was created by Transmission from a downloaded torrent:

drwxrwxrwx   2 sc-transmission transmission       4096 Mar  1 23:07 FolderName

and it's content (I trimed some of it, there was about 30 files with the same permissions in there, but kept 2 to demonstrate):

ash-4.3# ls -la
total 1885788
drwxrwxrwx   2 sc-transmission transmission      4096 Mar  1 23:07 .
drwxrwxrwx 266 sc-transmission sc-download      36864 Mar  2 04:45 ..
-rw-rw-rw-   1 sc-transmission transmission     10889 Mar  1 23:05 FileName.nfo
-rw-rw-rw-   1 sc-transmission transmission  50000000 Mar  1 23:07 FileName.rar

[elisimpson]

Yep I'm seeing same as @SX86 ... with the additional note that the dirs and files for transmission under @appstore are also all sc-transmission:transmission. As far as I can see sc-download isn't being set anywhere (as a user or group).

[Safihre]

Repeating it again: sc-transmission is part of sc-download. The problem here is different, it's the problem of mixing Synology and Linux permissions that I still have to investigate.

[elisimpson]

Maybe it's because the old transmission user ID was 100, same as the group ID for "users"?

(from etc/passwd) transmission:x:100:100:Transmission User:/usr/local/transmission/var:/bin/sh

The question I have is all the group owners being set to "transmission" an issue we should be concerned about? If it's no big deal, I'll move forward, but if it's supposed to be "sc-download" I'd rather not have to fix ownership later on potentially 1000s of files if I can avoid it.

[WolfH]

Could you try once more to set/add sc-download to /volume1/homes/admin/bittorent? Seems something set Linux permissions on that folder and the files in there are owned by transmission.

I've set group permissions for the bittorrent folder and everything inside to sc-download, restarted the NAS but am still running into the same issue... :(

[tweakert]

Exactly the same problem here. After updating Sonarr to latest version, it's not possible anymore for Sonarr to move files from Sabnzb download folder to the Sonarr folder (access denied/no premission).

[JonasL1]

SickRage permissions are also gone after the update of Transmission.

[elisimpson]

One other additional tidbit of info: the "sc-transmission" user and "transmission" group have the same ID: 190144. Maybe that's why it's is setting the group to "transmission" instead of "sc-download"?

[ymartin59]

@elisimpson "sc-transmission" is created by DSM 6 package framework, and as a user requires a default group, it creates "transmission" with same ID. So no worry about it. "sc-transmission" is member of group "sc-download" even if you do not see that technical user in DSM user/group management (as explained and detailed in package upgrade wizard, you probably have not read !)

[ymartin59]

Please open DSM user/group management interface and try to add user "sonarr" (or "radarr") as "sc-download" group member. If I guessed right, it should fix your permission denied troubles. Please report feedback. CC @Safihre

[SX86]

@ymartin59 that can't be done from the DSM group management. sonarr is not listed as a user in DSM. I was able to solve the issue partially by changing the umask setting in Transmission's "settings.json". I just find it strange that Transmission is now setting the group for downloaded files as "transmission" instead of "users", or "sc-download".

[Safihre]

What did you set now for umask setting and what has changed after that in how it writes the files? Maybe that could be the solution! The group is set by DSM when running the package, it's the same the package name. This is how Synology says we should do it but SynoCommunity just ignored that before (if I understand correctly).

[ymartin59]

@SX86 I guess your download "share" folder was pre-existing to upgrade. I am interested to know if manually granting "sc-download" group to that "share" folder from DSM File Manager would fix your trouble.

[ymartin59]

@WolfH I wonder if your trouble may come from your specific download location (a directory in home folder): /volume1/homes/admin/downloads. Packages have been designed and tested to write in DSM "share" folder.

[WolfH]

I just saw the latest update for the Sonarr and Radarr packages. Installed them and now everything is working again! Don't know what was fixed exactly, but all's well that ends well!

[Safihre]

Really? Cool!

[elisimpson]

Is there any reason why we shouldn't re-add sc-transmission to the users group? Seems like kind of an arbitrary choice to remove it that causes a lot of permissions issues with legacy files/folders.

[Safihre]

@ymartin59 @BenjV what do you guys think? At this point I kind of agree, we would resolve all this problems if we use the syno_user_add_to_legacy_group function. So that it only gets added if the old package user was part of users. Because for fresh installs the sc-download way does work, it's the old files causing the problems. And also that some packages already use sc-download (Sonarr/Radarr), while others do not yet (sabnzbd/nzbget)..

[BenjV]

Please don't add this sc- users to the users group or use old legacy users that are part of the "users" group. That will kill the whole purpose of running packages with less privileges. Every account on DSM is a member of the group users, so you cannot protect files/folder from any user.

I know that was the case in the past, but this was the major reason why everything had to change. Don't keep this very faulty situatie alive for the sake of compatibility.

[ymartin59]

My point of view is to instruct users how to fix permissions in File Manager thanks to a proper wiki page. Applying sc-download permissions to existing folders/files is not so a complex task (and automate it in package installer is not an option - may be too long/slow)

[elisimpson]

Fair point about why we shouldn't make the change. The problem is there's really no explanation or guidance from Synology about why that change was made and how to adapt legacy systems to the new rules. I'm sure they don't want to scare users with a bunch of tasks to do, but just leaving us in the dark is bad. 99.9% of the files on my server are owned with the group set to "users"

[tweakert]

I uninstalled everything and did a reinstall. And did a new setup. Got the following error trying to update GUI from Sonarr: Error occurred while executing task ApplicationUpdate: Access to the path "/tmp/nzbdrone_update/NzbDrone/UI/Content/FontAwesome/FontAwesome.otf" is denied. And also the newly setup download folder is denied. Something definitely wrong with the permissions.

[Safihre]

@tweakert restart your NAS first before trying to update Sonarr.

@BenjV / @ymartin59 I agree fully, but from posts here it seems it's not always working. If you scroll a little up you see these 2 users posting the ownership info of their whole path and even though it has the right groups and users, they still have problems. How could that be?

@elisimpson during the update it was shown in bold and red text that you should do this applying of permissions via File Station. What more can we do? Make it blink?

[BenjV]

I think it is a Sonarr issue. In the service file of Sonarr you can set the permissions (user and group) for the downloaded files and most likely that override de default permissions that should be inherited from the folder and so loose the group permissions of sc-download.

[ymartin59]

@BenjV Not sure if it is Sonarr fault, but it may help to configure it properly to avoid troubles. Here is a Sonarr screenshot with "Advanced Settings" enabled for file "Permissions".

[BenjV]

Correct and that information ends up in the service file of Sonarr. If someone enter something in the chown fields for user or group then the file permissions will change. The group should be empty or else sc-media/sc-download

[Safihre]

Why blame Sonarr? I would say Transmission, especially cause here a user says that changing the umask settings within Transmission fixes things: https://github.com/SynoCommunity/spksrc/issues/3192#issuecomment-370195052

And it should also be noted that the SynoCommunity package specifically forces a umask setting: https://github.com/SynoCommunity/spksrc/blob/master/spk/transmission/src/settings.json Not completely sure what that setting does, but it might explain the behavior we see that's so Transmission specific.

[ymartin59]

@Safihre Sounds right... So there is no reason to postpone Deluge publishing ?

[ymartin59]

I have installed and setup Transmission to use /volume3/downloads/transmission/ subfolders and Linux permissions have been discarded on /volume3/downloads for my "regular" user over ssh:

yma@DiskStation:~$ ls -la /volume3/
d---------+   4 root            users            4096 Mar  4 23:06 downloads

To fix that situation, I added back permissions to group users in File Station. I just wonder what part of package scripts may have such impact, as none triggers users group permission remove - except if synoacltool -add do not really "just add" requested permission.

[SX86]

@Safihre My umask setting is now set to "0" in settings.json. umask 0 is supposed to set 777 (rwxrwxrwx) on every files and folders Transmission creates. In my case, it only sets the permissions to 666 (rw-rw-rw-). I think this may be caused by the fact that Transmission can't set the execute permission since it is not the owner (as a group and user) of the folder it creates the download files and folders in. I think (I would have to confirm) that if I want to use the setting in Sonarr that changes the date stamp of the files to match the Air Date, it needs execute permission on the file.

However, even if the permissions are 666 on the files, it allowed Sonarr to import the file to the configured TV show's folder. I want it to be 777 for Sonarr to be able to set the date stamp on the file, but at least, now it works.

[6uillaume]

Hello, I have a similar issue after updating to the last version of Transmission. Only the admin account can access the /volume1/downloads folder. Transmission seems to be unable to reach the files. I was not able to find a way to give to the users the right to access the downloads folder. I tried to reboot the syno, uninstall/reinstall the package without success. My files and folders are attached to the group transmission that doesn't exist in the Control Panel (sc-download exists) so I attached the files to sc-download and add member my users in this group. But it doesn't work.

[BenjV]

To be able to set the date stamp has nothing to do with 777. The last bit is the execution bit and is only usefull for files that can be executed.

The umask should be set to 002, that will allow read and write access to files and folder from users who are in the same group.

What you need to do is make sure the folder and all the subfolders and files have been granted read/write access for the groups sc-media and sc-download. You have to do this with FileStation. Got to the top folder, choose properties and grant permission for sc-media and sc-download groups. Do it recursively to make sure that all the subfolders and files get this privs.

In alle applications like Transmission and Radar be sure not to set the group to something else because they do that with a "chown" command which put the file exclusively in one group. Then when an application creates a file or folder it inherit the privileged settings from the folder above that you just granted read/write privs for sc-media and sc-download.

[tweakert]

What you need to do is make sure the folder and all the subfolders and files have been granted read/write access for the groups sc-media and sc-download. You have to do this with FileStation. Got to the top folder, choose properties and grant permission for sc-media and sc-download groups. Do it recursively to make sure that all the subfolders and files get this privs. That doesn't work for me though (btw not very good at this kind of stuff ). In Group you have sc-media and sc-download. Both of them don't have any members. Granting read/write access is only possible for one of the 2 groups, that is sc-media or sc-download group. The download folder is owned by sc-sabnzb...

[ymartin59]

@Safihre I wonder if last chown ${EFF_USER} may have side-effect to discard any ACL settings on folders... So question: is chown is really needed, and if so probably it should be moved first. Just ideas, I have not tested yet to confirm.

[Safihre]

@ymartin59 Which chown do you mean? In generic service or in the package?

[BenjV]

@tweakert You right you are not very good at this. The new packages are running as a User that is hidden, so they are not seen by the DSM management interface. That's why we use Groups to get access to the files those packages create.

Users can be a member of multiple groups and the hidden Users of new packages are members of the groups sc-media and sc-download (don't ask why there are two groups, I could not tell you that). So all those Users can access all files owned by one of those groups as long as the files have read/write privs for groups.

Normally applications just write a file to a folder and then the file will get the same owner as the folder it writing to, that's why it is important to create a top folder wich is owned by one of those two groups.

Some applications will set itself(or someone else) as the owner, but that owner is member of the sc-media and sc-download groups, so any User that is a member of one of those groups has access to those files. Just be very carefull not the set the group or some other user.

Except some package that does not do that and set something else (via a chown command), but those can mostly be configured to do the normal thing.

@ymartin59 Is it to late to get rid of the sc-download, because two groups are just confusing and don't add anything because all package have to be in both groups.

[dan2kx]

I'm having the same issue too, any steps to resolve the permission issue?

  at System.IO.File.Move (System.String sourceFileName, System.String destFileName) [0x00116] in <cb410c64c7fa4e8d9841a0cbe4173d66>:0 
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFileInternal (System.String source, System.String destination) [0x00000] in <7e93f23c2fc54b74802f7126f4e364f7>:0 
  at NzbDrone.Mono.Disk.DiskProvider.MoveFileInternal (System.String source, System.String destination) [0x00076] in <bcf9221f6ec744e6bfb4719186592925>:0 
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFile (System.String source, System.String destination, System.Boolean overwrite) [0x000e3] in <7e93f23c2fc54b74802f7126f4e364f7>:0 
  at NzbDrone.Common.Disk.DiskTransferService.TryMoveFileTransactional (System.String sourcePath, System.String targetPath, System.Int64 originalSize, NzbDrone.Common.Disk.DiskTransferVerificationMode verificationMode) [0x0008f] in <7e93f23c2fc54b74802f7126f4e364f7>:0 
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbDrone.Common.Disk.TransferMode mode, System.Boolean overwrite, NzbDrone.Common.Disk.DiskTransferVerificationMode verificationMode) [0x003ce] in <7e93f23c2fc54b74802f7126f4e364f7>:0 
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbDrone.Common.Disk.TransferMode mode, System.Boolean overwrite, System.Boolean verified) [0x0000e] in <7e93f23c2fc54b74802f7126f4e364f7>:0 
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.TransferFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Tv.Series series, System.Collections.Generic.List`1[T] episodes, System.String destinationFilePath, NzbDrone.Common.Disk.TransferMode mode) [0x0012c] in <907396538063488ebd3918dbee5833ec>:0 
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.MoveEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode) [0x0006c] in <907396538063488ebd3918dbee5833ec>:0 
  at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode, System.Boolean copyOnly) [0x0017c] in <907396538063488ebd3918dbee5833ec>:0 
  at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.Import (System.Collections.Generic.List`1[T] decisions, System.Boolean newDownload, NzbDrone.Core.Download.DownloadClientItem downloadClientItem, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode) [0x00277] in <907396538063488ebd3918dbee5833ec>:0

drwxr-xr-x  16 DownloadStation DownloadStation      4096 Mar  7 04:09 @download
drwxrwxrwx  18 root            root                 4096 Mar  7 04:20 Download

My downloads folder is owned by root?

[smoker1000]

Same problem with sonarr for me. Applied the latest version from syno of sonarr and some, not all, but some, of the folders under tv shows in video, now have the owner as 101 and the group as users. Tried setting tv show folder as group sc-download and also sc-media and both would not let sonarr move any files. What a mess now. As I cannot see if either group holds sonarr, I have no way of knowing if the update did what it was supposed to do. especially since it only changed the owner and group of some of the tv shows. Now I have over a hundred folders with mixed permissions!!

[SX86]

General question to all that are having issues; is the place (share) where you are downloading your files too, and where your files are imported/copied too, are they "Converted to Windows ACL", or created with DSM 6? I think that this is what may be causing the whole issue for people on DSM 6. My volume1 was created with DSM 4.0, in 2011, and I think that all newly created volumes create all the shares using the "Windows ACL" method, vs regular Linux style permissions. In my case, my shares are mostly all Linux-styled, hence why I haver to fix the permissions manually, at least once, for Sonarr and Transmission to work together properly.

If any experienced users here would be able to respond, we may be able to pinpoint the origin of those permissions issues!

[smoker1000]

In my case they were created by DSM years ago. I am not smart enough to play with anything else in settings :-)

[BenjV]

I think you are on the right track. I have an older NAS (DS414) and there I have a mixture of shares with and without "Windows ACL" where al the share without stem from the DSM 5 time I have a newer test NAS from after DSM6 and there all the shares are with "windows ACL".

It seems logical that using ACL privs for the new packages will only work for shares created with ACL privs. If that's the case none of the package will function correctly under DSM 5 and under DSM 6 all old shares have to be converted to using 'Windows ACL".

[dan2kx]

Mine too are old shares i'll try and convert to ACL...

[dan2kx]

That didn't seem to work either

[Kilay]

I had the same permission errors in Transmission and Sickbeard Custom (Medusa fork) and after converting my shared folder to "Windows ACL" and checking that sc-media and sc-download had the right permission, it is working great.

Thank you @BenjV

[Safihre]

Hmmm, now I wonder if there's a way to do this on the command-line so we can do it during upgrades!