Replies: 4 comments 4 replies
-
@fredhen Thank you for this report and review. |
Beta Was this translation helpful? Give feedback.
-
Same problem here, after unrar (with using x -ai) the permission gets set to this: |
Beta Was this translation helpful? Give feedback.
-
@velimir1845 @patricktrabergooglemailcom
On my system (Synology DS215j / DSM 7.1.1-42962 Update 6) Sonarr v4 + NZBGet is working correctly. |
Beta Was this translation helpful? Give feedback.
-
@phnzb Was that changed somehow in one of the latest updates? I remember that used to work until some time ago. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I'm having a problem with Medusa not having permission to the completed directory due to the permissions on the file not having inherited permissions. My Medusa user is sc-medusa and NZBGet is sc-nzbget (from the Synocommunity), but also tested installing it with wget with the same result.
I am making use of NZBTOSICKBEARD to send a postprocessing command to Medusa to pick up the file from the folder, process it (move) and then delete.
I can see the following in Medusa:
If I manually apply permissions to folders and files to give sc-medusa permissions then Medusa is able to process it as expected.
The problem from what I can gather is that the Unpack happening with NZBGet is not inheriting the permissions causing the sc-medusa user to not have the required permissions.
From my hours of searching and playing it seems like
unrar x -ai
is the solution, but that does not seem to work for me. With that in place I have also tried UMask set to 0000 and CHMOD set to 0777 (with UMask at 000 and 1000) and the results are the same. This was first tried with the 24.0 stable version and then the 24.1-testing-20240506 version.Part of the rabbit hole led me to a similar issue for SABnzbd mentioned in SynoCommunity with a big discussion in the linked SABnzbd pull request which seems to come down to -ai again, but without any CHMOD which seems to mess up with Synology's ACLs which I think is what's happening here.
To give you an idea:
The completed folder has inherited permisisons (from the share's root as set based on Permission Management mentioned in the SynoCommunity):
I can also see this with ls -l:
The created folder during unpack also has inherited permissions along with its own:
And I can see this with ls -l which seems to lose the ACL as there's no + at the end anymore although the inherited permissions are still there:
And the resulting file:
And I can see this with ls -l:
Can anyone help me in the right direction? The main objective here is for Medusa (sc-medusa) to be able to pick up the files and move them and delete it afterwards.
Note:
This was working perfectly (with the SynoCommunity using nzbget.net as I didn't update to the .com version yet), but I had a drive failure and decided to redo the NAS from scratch. That came from DSM6 though, so I can't say if the sc-download group that existed still worked after the DSM7 upgrade, but that's obviously no longer there, but I think it's more likely that I never 'converted' to ACLs.
No idea if any of the recent permissions issues are related. I did try the testing version, but like I mentioned there does seem to be something with the Synology ACLs here.
#263
#228
#165
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions