I use Sonarr and NZBGet and this as been working perfectly for some time, however seems the recent update (6.12 maybe 6.11) has moved the NZBGet folder and i now found that now Sonarr nolonger has permissions to move the completed download.
The Completed folder now looks like
drwxrwxrwx 2 nzbget dietpi 4096 Aug 8 07:43 The.100.S05E13.WEB.x264-TBS-xpost
where before it was dietpi dietpi
anyway to fix this so Sonarr has permission again… i now have to manual chmod the files to get it to work which isn’t ideal .
I opened an issue to check again what could break permissions after v6.11/12 update.
For fresh installs it worked fine, but maybe we applied the permissions wrong for existing installs: https://github.com/Fourdee/DietPi/issues/1999
ok great so it was something to do with the upgrade then
Any quick fix i can run on the shell to get it to work again?
I did try adding sonarr to the NZBGet group but that didnt do anything, as the file created is 644 so it still doesnt have move permissions.
currently the hammer method is to chmod -R 777 *
Okay I checked a bid:
The NZBGet folder should be owned by nzbget:dietpi, that’s correct, and it should be chmod to 775, like the whole dietpi_userdata folder.
As Sonarr service runs as “sonarr” user but “dietpi” group, it should have write access to the the nzbget folder.
Adding sonarr to nzbget group does not change something, as the above has the same effect.
But now, hmm you say the files are created by nzbget with 644 permissions? Okay yeah that would indeed breaks write access for group members. Either nzbget needs to create files with 664 permissions (660 would be possible as well), or Sonarr needs to run as same user (not just same group).
So for now in you case, chmod 777 hammer is not needed, chmod 660 is sufficient. But yeah we need to find a way to make NZBGet and possibly other software creating files by default with 664 (or 660) permissions.
thanks for the update.
I think i have got it working but not too sure if both or one of the following did it.
I added the Sonarr to the NZBGet group as i mentioned, but i have also set the UMASK setting in NZBGet to 0000 (was 1000)
and restarted NZBGet Service.
so not sure what of the above fixed the problem… maybe the service restart sorted.
i will keep i eye out, i am not sure what the actuall file permission was ie 664 or 660 as the file was moved and imported before i could check.
incidently the other thing that broke during the update was i couldnt login to NZBGet as root, it had changed to Admin instead,
only way i could figure that out was by finding the conf file.
Ah the umask setting did it, this is what we need to adjust to 0003 or 0007 or 0117, all should work.
Yeah about changed login name: We really need to take care to backup existing configs within install/reinstall script and/or carefully change only what is really needed.