Your synology utilizes ACLs to add an additional security layer. That helps in not needing to fiddle around with the user:group in the *nix layer.
It took me a while to realize, the best thing is to stay away from the *nix layer, and use the ACLs what they are intended for.
In a “clean” setup, as long as the sc-download or sc-media group has been granted access in the Synology layer.
drwxrwxrwx+ 3 Me users 4096 Mar 6 07:49 Deluge
drwxrwxrwx+ 2 deluge users 4096 Mar 6 07:52 Once…
The + indicates an ACL is present and utilized on the folder
-rwxrwxrwx+ 2 deluge users 1997941137 Mar 6 07:53 Once…mkv
The + indicates an ACL is present and utilized on the file
Even though it seems that it all has 777, actual access is restricted by the ACL. And that’s what you want, because the ACL are the permissions in the synology layer.
Just because we got used to fiddling in the *nix layer due to packages utilizing hidden users, that doesn’t mean that was ever a good idea.
In this example, just grant the group sc-download (which contains the sc-nzbdrone user) read/write in the synology layer on the Deluge folder, and it will have no problem processing your files.
If you have other packages using hidden users, you could always add those to an existing group using for example “sudo synogroup --member sc-media user1 user…”.
But please note that will overwrite the group so all users already present in the group need to be in the command, or they will be lost.