Permission issue while updating Sonarr

[jelmerj]

For new Package Requests, see the guidelines

Setup

Package Name: Sonarr
Package Version: 201802280-12

NAS Model: DS214play
NAS Architecture:
DSM version: 6.1

Expected behavior

Sonarr advertised an update. I expected it to update without problems.

Actual behavior

The update failed with this error: Error occurred while executing task ApplicationUpdate: Access to the path "/tmp/nzbdrone_backup/config.xml" is denied.

Output of ls -la /tmp at the time:
drwxr-xr-x 2 100 users 100 Feb 27 19:58 nzbdrone_backup
drwxr-xr-x 3 sc-nzbdrone nzbdrone 80 Feb 28 21:00 nzbdrone_update

As you can see the user/group of nzbdrone_backup are incorrect. I decided to just remove the dir and have sonarr recreate it itself. That worked like a charm and the update was succesful afterwards.

I'm not sure if the package handles the permissions on this directory?
The same appears to be true for radarr:

drwxr-xr-x 2 radarr users 80 Feb 27 20:10 radarr_backup
drwxr-xr-x 5 radarr users 480 Feb 27 20:11 radarr_update

As you can the the dirs are owned by radarr/users instead of sc-radarr/radarr

[Safihre]

The problem here is more Sonarr/Radarr related because it doesn't clear out the /tmp/nzbdrone* after the updates that it does. It relies on the OS to do that.
So the files there were created during a previous backup using the older version of the Sonarr package that used the old permissions system.
I am not sure when DSM clears the /tmp folder, but definitely on reboot/startup.

On my virtual-DSM I also experienced this problem as my /tmp folder filled up to 100% due to Sonarr updates and backups that were never cleared.

[jelmerj]

ah okay, that definitely makes it less of a priority, as you could just ask users to reboot their system as a fix for this problem. However, this problem is related to the new package version ofcourse, because of the user/group which come along. Are you guys detecting an upgrade from old-style to new-style package? If so, you might as well purge these 2 directories at that point (or fix the user/group)

[Safihre]

@ymartin59 what do you think?
A simple rm in postupgrade of these 2 folders could solve this indeed.

[ymartin59]

I have to look in detail. From my point of view, as installer script run as root, preupgrade should clean up target location before generating backup... and postupgrade has to apply permissions on files after copying files into var.

[Safihre]

No no this is different, it's about Sonarr's internal update that creates a backup some random time before the update, not the SynoCommunity package's update.

[ymartin59]

You already know that I prefer to control package content and so disable application autoupdate process... If application expects to read back its content, probably postupgrade has to change permissions on that temporary folder. Remove it may break configuration migration process for upgrade.

[ymartin59]

@Safihre May you please submit a PR with your fix proposal - either folder removal or owner change - so that I can publish Sonarr/Radarr again.

[SX86]

I've had the same issue as @jelmerj after updating Sonarr from the Package Center in DSM. I went into Sonarr, it said it had an update, tried to install it, only to find that it failed because access was denied to that folder. I simply used chown to change the owner of the folder and files in the folder, and that worked.

But now, I'm getting the following warnings in the log:

Unable to set date of file [/volume1/video/TV/file.mkv]: Access to the path "/volume1/video/TV/file.mkv" is denied.
Unable to apply permissions to: /volume1/video/TV/file.mkv: Error setting file permissions: EPERM
Failed to get runtime from the file, make sure mediainfo is available

That was never an issue before.... but now it is, since the last package update from SynoCommunity.
I was able to resolve some

[Safihre]

@SX86 Could you go into System and check if it is giving a mediainfo problem? If it is, what system are you using?
The permissions problem I think is related to what I describe in the PR for this fix #3190.

[SX86]

DS916+ running DSM 6.1.5-15254 Update 1
Sonarr Version : 2.0.0.5153
Mono Version : 5.8.0.108
AppData directory : /volume1/@appstore/nzbdrone/var/.config/NzbDrone
Startup directory : /volume1/@appstore/nzbdrone/share/NzbDrone

@Safihre If I go under System (in Sonarr), under Health, it says "No issues with your configuration"
I changed some permissions on the folders where the files were being downloaded, as well as changing the umask setting in Transmission. Hopefully, that will help to resolve the issue. The mediainfo warning is a bit confusing, because it seems to say the binary is not available or can't be accessed... but maybe the real message should be "mediainfo cannot access the file, so I'll give you a warning for it".

I think the trigger to my permissions problem was that the new Sonarr package uses a different user and group name for permissions? Am I correct?

[Safihre]

@SX86 You are right. Today there was a new version of Transmission SynoCommunity package that now also uses the same group as Sonarr/Radarr, so maybe check if you are getting that update yet? This should bring things back in sync.

[SX86]

@Safihre I just installed the update to Transmission, and I got rid of one of the warnings, the one for mediainfo. I still have those 2:

Unable to apply permissions to: /volume1/video/TV/file.mkv: Error setting file permissions: EPERM
Unable to set date of file [/volume1/video/TV/file.mkv]: Access to the path "/volume1/video/TV/file.mkv" is denied.

From what I can see, new downloads are now using, for folders:
drwxrwxrwx 2 sc-transmission transmission 4096 Mar 1 20:23 FolderName
and
-rw-rw-rw- 1 sc-transmission transmission 622006612 Mar 1 20:23 file.mkv
for files.

It used to use, for folders:
drwxrwxr-x 2 transmission users 4096 Jan 7 19:27 FolderName
and
-rw-rw-r-- 2 transmission users 931541903 Jan 11 22:01 file.mkv
for files.

Since the update, I was expecting Transmission to now use/apply the group sc-download, instead of the group transmission.

Also, it doesn't look like the umask 0 setting isn't being applied to newly downloaded files, but that's probably a seperate issue.

[Safihre]

@SX86 This is the way its supposed to be, because sc-transmission is part of sc-download.
Now can you check in File Station if the group sc-download has the permission to change access rights? It's hidden pretty deep. But I think it doesn't have that special flag maybe.

[BenjV]

I think the issue is that the application do not set the permissions of files and folders they create.
If an application is using an existing folder then the files just get the same priv as the folder above.
But if the folder above was not granted privs for sc-download before, the application cannot write to that folder.
The package installation cannot do that because it does not know which folder you are going to use.

So you have to grant sc-download read/write privs to the folder /volume1/video/TV with FileStation (or chown on the commandline) before the application can write to folders or files there.

[Safihre]

@ymartin59 or @BenjV could you maybe explain to me again why we use for example sc-nzbget:nzbget for packages?
Why can't we do sc-nzbget:sc-download?
I missed this part in the original setup of generic service.

[ymartin59]

@Safihre Synology DSM SDK "Lower privilege" support does it for "us". I let you read corresponding section: https://developer.synology.com/developer-guide/privilege/preface.html
For ease of maintenance, @BenjV and I agreed to comply as much as possible with SDK so that to avoid any incompatibility at future DSM minor/major upgrade.

[ymartin59]

By the way I wonder if it is possible to change start-stop-status process default group to sc-download before forking... it may help.

[BenjV]

A process (and so also a script) does not have a group.
A process is only run by a user and has no group affiliated.
A user can be member of one or more groups.

And the start-stop-status script is run as root as defined in the privilege file.

[ymartin59]

@BenjV In fact start-stop-status script is run with package user account by defaults in spksrc.
I wonder if setfacl is available on DSM to enforce GID to sc-download for newly created file/folder in any folders of a "share" location configured for an application

[ymartin59]

@BenjV About process GID, I mistaken with shell behavior when using newgrp command

[BenjV]

start-stop-status script cannot be run as package user account because it uses kill -0 to view the status of a running pid.
This command can only be used if the script is running as root.

I think that all the ctrl-scripts are run as root unless you specify it as something else in the "privilege" file.

[ymartin59]

@BenjV I confirm spksrc generates conf/privilege with run-as: package as defaults configuration. Actions start, stop and status run as unprivileged user account and no issue/failure until now around kill -0 usage. What is your point about it ?

[BenjV]

A kill -0 command needs root privilege otherwise you get an permission error.
Ergo the start-stop-status script is running with root privileges.
That default does not count for the ctrl scripts.

I tested it and all cntrl scripts (perinstall, postinstall etc.) are running default with root privileges.
You have to set them explicite to "package" in the conf/privilege file per script, but don't do that, they need to be root.

[ymartin59]

@BenjV I have here a small "working" package set with package privilege: mosquitto, jackett, transmission, sslh, radarr, sonarr, deluge...
I have just tested stop/run sequence on them confirming with ps. kill -0 seems to be OK as far as target process runs with same UID as kill.

Here is conf/privilege file we use as template

{
	"defaults":{
		"run-as": "package"
	},
	"username": "USER",
	"ctrl-script": [{
		"action": "preinst",
		"run-as": "root"
	}, {
		"action": "postinst",
		"run-as": "root"
	}, {
		"action": "preuninst",
		"run-as": "root"
	}, {
		"action": "postuninst",
		"run-as": "root"
	}, {
		"action": "preupgrade",
		"run-as": "root"
	}, {
		"action": "postupgrade",
		"run-as": "root"
	}]
}

[BenjV]

Your missing the point.
All scripts including the start-stop-status script are running as root as long as you don't say anything else.
You don't even have the start-stop-status script in there only if you add it in and give it explicit other privs with:

"run-as": "package"

it will change.

The defaults on top of the conf/privilege don't effect them, only if you specific give them other privs.

And they should run as root, because they spawn the actual application with a run-as and to be able to do so they have to be root.

Also in the preupgrade for example you should want to save some configuratie and or database files which you can restore in the postupgrade script.
Then you have to chown those files back to the user:group of the applicatie and such a chown can only be done as root.

I can give lots of more examples, but believe me the scripts has to be root.
And changing priv on those script will not effect any app because they already are running as 'package'.

The whole discussion about not be able to access file between different apps is just because most people don't have clue on how privs settings work and on top of that, Synology has created a little management layer on top of the linux privs system to confuse things.

If I have some time left the coming days I shall write a small text about how it works on DSM.

[ymartin59]

I do not object all "installer" scripts runs as root in spksrc packages.
BUT on DSM 6, start-stop-status is run as "package" privilege without any trouble.

As an example, "mosquitto" process runs with package user "sc-mosquitto":

$ ps -ef | grep mosquitto
sc-mosq+ 10985     1  0 Feb24 ?        00:06:21 /volume1/@appstore/mosquitto/sbin/mosquitto -d -c /volume1/@appstore/mosquitto/var/mosquitto.conf

Whereas script uses no "su" or "sudo": https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.service.start-stop-status#L49

And I confirm again, there is no need for kill -0 to run as root to operate https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.service.start-stop-status#L81
as far as kill and target PID runs with same user ID.

[LaChoz]

Hey guys,

Updating the post. I've also got a permission issue on my Sonarr.
I tried several things :

uninstall / reinstall with backup restore
convert ACL download and video folder
check permission and allow read/write to sc-download on download and video folders
uninstall / reinstall without restoring backup
no success, I still get in my log things like :
ExtraService failed while processing "access to path /Volume1..../show folder" is denied

I'm desperate for a solution ...

Thx for any help

[BenjV]

What's the point in asking the same question on multiple places in this forum?
Not you have to go hunting for the answer.

[Safihre]

Closing, see https://github.com/SynoCommunity/spksrc/wiki/Permission-Management
Original issue is resolved.