Sonarr version (exact version): 4.0.9.2244 Mono version (if Sonarr is not running on Windows): OS: Synocommunity Debug logs: Description of issue: I’ve been maintaining a home Synology NAS that runs all apps such as Plex, Sonarr, Radarr, Overseerr, Nzbget, etc. Lately both Sonarr and Radarr give me errors when downloads are completed. Basically Nzbget downloads to the folder /volume1/NzbgetDownloads/TV Shows and then Sonarr picks it up, places it in /volume1/Downloads/TV Shows. But then Sonarr leaves the downloaded file in the folder /volume1/NzbgetDownloads/TV Shows, shows an error under Activity-Queue - Failed to import episode, destination already exists.
I have checked Linux permissions multiple times, attached permission screenshot. Funny thing is that whenever I go into permissions, edit them to the same settings, the issue gets fixed for the time being. But when the next download happens, the issue is back.
I’ve check the logs, shows “System.UnauthorizedAccessException: Access to the path ‘/volume1/NzbGetDownloads/TV Shows/Kaos.S01E03.1080p.WEB.H264-ETHEL/GWg8ciVk7uHPCZjrKbFU.mkv’ is denied.
—> System.IO.IOException: Permission denied”.
The only way I can fix this reliably is to use the Synology folder permissions and re-check “apply to this folder, sub-folders and files” to the root of NZBGet (where the downloads go). That instantly deletes all the downloaded folders and fixes the error message in Sonarr for each failed move. But, as soon as I download a new file, the problem returns.
Clearly a permissions issue but it shouldn’t keep cropping up like this…
Wow finally someone who is going through exactly what I’m going through.
Yeah I don’t understand why the permissions have to be manually forced everytime you want Sonarr / Radarr to finish off the downloads. Its got me thinking this might be a Linux issue.
I tried to follow the Trash guides step by step but still never been able to figure out the permission issues.
The problem is 100% permissions and I have not yet found the solution. I, too, followed the trash guides as they relate to permissions (or think I did) and it does not fix it.
I just downloaded a test file to follow the permission problem. Here is what I see:
Root folder for downloads (/volume1/NZBGet/) has read/write for all users (I forced this for testing)
The next two levels down (completed and completed/TV) have those same permissions.
The test file then created a folder inside /volume1/NBZGet/completed/TV and that folder has different permissions. It does not allow delete by user “sc-nbzget” and the “everybody” user has “read” permissions instead of “read/write” like the other folders.
Then, you look at the actual file in the new download folder and those permissions are even more restrictive.
So, when NZBGet creates a new folder or file, it is not inheriting the permissions from the higher folders, it is setting new permissions and those permissions are not allowing delete. When we manually set the permissions to “all enclosed folders”, the system can then automatically delete and the process finishes as designed.
So, where is NBZGet getting the permission flags to set on the files and folders it creates? I can’t find these anywhere in the NBZGet settings. I also don’t see where they are set in a post processing script. The only part of the conf file I can see anything related to permissions is:
The option can also contain extra switches to pass to unrar. To the
# here defined command line NZBGet adds the following switches:
# x -y -p- -o+ *.rar ./_unpack/
#
# Switch "x" is added only if neither "x" nor "e" were defined in
# the option (this allows you to use switch "e" instead of "x"). switch
# "-o+" is added only if neither "-o+" nor "-o-" were defined
# in the command line. All other parameters are always added. Parameter
# "-p-" is replaced with "-ppassword" if a password is set for nzb-file.
#
# Examples:
# 1) ignore file attributes (permissions):
# /usr/bin/unrar x -ai;
# 2) decrease priority of unrar-process:
# nice -n 19 unrar.
#
# For other useful switches refer to unrar documentation.
#
# If unrar is in your PATH you may leave the path part and set only
# the executable name ("unrar" on POSIX or "unrar.exe" on Windows).
UnrarCmd=${AppDir}/unrar
Found the fix. Thanks to a Reddit post. Go into your NZBGet settings → Security and scroll to the bottom. Change the UMask to “0000” and save your settings. It now seems to be working correctly for me.
