Sonarr Permission issue driving me bonkers

[ghostwolf59]

Sonarr version (2.0.0.5322):
Mono version (5.10.1.57):
OS: FreeNAS 11.2-U3 (iXsystems)
Debug logs:
ImportApprovedEpisodes Couldn’t import episode /mnt/torrents/American.Gods.S02E03.720p.WEB.x265-MiNX[TGx]/American.Gods.S02E03.720p.WEB.x265-MiNX.mkv: Access to the path “/mnt/video/American Gods/” is denied.
DownloadedEpisodesImportService Import failed, path does not exist or is not accessible by Sonarr: /media/American.Gods.S02E03.720p.WEB.x265-MiNX[TGx]
Description of issue:
Hi,
I wonder if someone could tell me where I am going wrong with setting up permissions for sonarr

Just installed sonarr on my FreeNas 11.2-U3

Managed to get it up and running using jacket, transmission - it downloads what I am looking for BUT(!) fail to move completed downloads to my designated area - throws permission errors.
As a matter of fact the logs keep pointing to the /media folder not found or permission preventing the move.
This is somewhat interesting since I never nominated the /media folder to begin with - so not sure why its pointing to that.
My actual folder linked to viewing is /mnt/video (that is mapped to my tv show folder on another drive).
The permission on this media folder:
owner: 1002
group: 0

permission across root folder and video content set to 755

The sonarr uid is 351 where I made an attempt to change the permission of folders and files to my media user (8675309) along with adding the sonarr user to the group of the media
Didnt work - same error thrown.

Then I tried to map my video folder to the /media - no change

As a final desperate attempt I then set the permission to the folder and files to 777 - Same blimming error

So not sure whats going on here.

Basically all I want is for sonarr to be able to move completed downloads into the video area - everything else works perfect.

So to recap, I have a folder and file structure with a owner of 1002 and group 0 (wheel) with permission set to 755 that allow me via CIFS to control the content while other users only is given read only access.
Throwing in the sonarr user into the equation screws with my head - I assume I need to setup some group permission (which I tried), but not sure how I link this properly while preserving my overall control (i.e 1002:0 (755))

anyone familiar with FreeNAS 11.2-U3 onward that could provide some hints on this (please!!!) - this is driving me up the wall - especially when complete lack of control i.e 777 permission, still throws a permission exception.

Worth mention is that I have the same issue with radarr

[ghostwolf59]

Ok, Took me a while to find out that both sonarr and radarr need EXACT folder mapping to what transmission is using - Read over and over again in posts that mapping need to be exact, but never thought the apps were so dumb they couldnt use symbolics that points back to the exact path.
i.e if tracker jail mapped /media to point to /mnt/[drv]/folder and sonarr mapped its jail folder to /mnt/video pointing back to the same /mnt/[drv]/folder sonarr and radarr cant figure that out - -Instead I need to make sure sonarr mapped its folder to /media pointing to /mnt/[drv]/folder (exact match with how transmission mapped it internally within its container) - That comes across as utter dumb!!

• AND(!) nowhere is this clearly described as part of the setup *both sonarr and radarr and numerous posts
  Once I figured that out thinking it had something to do with permission it all worked - EXCEPT the final step where I want sonarr to change permission on the moved/copied content *both folder and file(s) - Set it up, but keep failing where the moved/copied content ends up with media user and group with limited access on the group

As part of solving what appears to be a common problem I wonder why sonarr & radarr cant resolve locally defined symbolic linked path to where it actually is pointing actual path - This notion of being forced to use exact naming between jails comes across as dumb and I simply cant see why that cant be resolved quite easy. A jail definition pointing to a physical location = use the physical location rather what the container jail is using internally = it all equates to the same physical location

[markus101]

but never thought the apps were so dumb they couldnt use symbolics that points back to the exact path.
i.e if tracker jail mapped /media to point to /mnt/[drv]/folder and sonarr mapped its jail folder to /mnt/video pointing back to the same /mnt/[drv]/folder sonarr and radarr cant figure that ou

How would Sonarr know that two completely different paths are pointing to the same path unless you tell it that?

Transmission tells Sonarr where to import from, Sonarr doesn’t assume any path on disk could be that folder.

Either Sonarr needs to see the exact same path or you use a Remote Path Mapping in Sonarr to tell it which local path to use for the given remote path. It’s not magic.

[ghostwolf59]

How would Sonarr know that two completely different paths are pointing to the same path unless you tell it that?

Why is the physical location within sonarr’s container important?

• If I decide to use /media within sonarrs container (jail) to point to the physical pool transmission is using and use /torrent within transmissions container(jail) to point to the same physical pool it should’nt make any difference.

I would have thought that sonarr simply could use the symbilic mapping within the sonarr container regardless of naming on a completely separate container (transmission) - Regardless of internal naming and container mapping, they both points to the same physical location on the target disk.

I think this ought to be 100% feasible to accomplish - Simply use the container mapping and use the location it actually is pointing to - And agree, it should not be magic (more a logical step)
Binding separate services like this makes both services highly vulnerable with high level of chances of breaking one or both services.

I also object about the lack of info covering this issue - Could have been easy enough to include an example of two separate jails sonarr need to communicate with and how the mapping and naming is expected to look like.

[markus101]

Why is the physical location within sonarr’s container important?

The physical location doesn’t matter, what Sonarr receives from the client is.

If I decide to use /media within sonarrs container (jail) to point to the physical pool transmission is using and use /torrent within transmissions container(jail) to point to the same physical pool it should’nt make any difference.

Sonarr would get /torrent in that example and not know how to find it. It’s like me telling you I live on 123 st, but in your town you don’t have a 123 st, you’d be unable to find what I’m telling you about.

Simply use the container mapping and use the location it actually is pointing to

Sonarr doesn’t know about the other container’s mapping, so how do you imagine that’d actually work?

I also object about the lack of info covering this issue - Could have been easy enough to include an example of two separate jails sonarr need to communicate with and how the mapping and naming is expected to look like.

Feel free to document it, there are dozens of threads here and reddit and this is a damn good explanation of it (in the context of docker, but close enough): https://reddit.com/r/usenet/wiki/docker

[rhom]

I would have thought that sonarr simply could use the symbilic mapping within the sonarr container regardless of naming on a completely separate container (transmission)

what symbolic mapping? containers are essentially individual isolated machines, they dont talk to each other unless you tell them to - and even then its just opening ports for applications inside the containers to talk to each other - the underlying OS or host doesnt tell them anything about any other containers that are running (or not running) either.

if you want two containers to see the same path then you need to map the same base volume in both of them

eg, my containers;

• transmission has \downloads mapped, and uses \downloads\transmission\completed\sonarr\... or \downloads\transmission\completed\radarr\... depending on who started the download
• sabnzbd has \downloads mapped, and uses \downloads\sabznbd\sonarr\... or \downloads\sabznbd\radarr\..., again, depending on the category of the download
• sonarr and radarr have both \downloads and \media mapped so that when transmission or sab tell them the file is, for example, here \downloads\complete\sonarr\torrentname\torrentfile.mkv then they have that path and can find the file to move it to \media\tv\series\season\ep.mkv

if i dont map a host path to a volume for \downloads in sonarr then how would it know where to find that path when transmission tells it thats where the file is? it can only access whats in the container, and that path is not in it, so it fails.

I also object about the lack of info covering this issue

to be fair, volume mappings are standard docker stuff.

if youre outside docker then it doesnt really come into the picture. youd have a similar issue with multiple hosts but then you need to map/mount a drive to the other hosts and setup remote path mappings for them (which i think theres a chunk of info on).

Could have been easy enough to include an example of two separate jails sonarr need to communicate with and how the mapping and naming is expected to look like.

the only expectation is that sonarr has access to the “absolute” path the download client gives it back - or the “renamed” one a remote path mapping would generate from it

btw, whats jail a reference to? typically it means prison, but i dont get the link to sonarr.

[ghostwolf59]

the mapping is indeed a symbolic mapping within each isolated container pointing back to the physical drive/folder.
There’s no other way it can be described - if it wasnt, then why even bother mapping a container folder to an external location? You could just as well mapped a direct path to the external data!

• As soon as the symbolic link is established the container gain access to externally stored data - With no data actually stored within the container itself - its still located on the external location - So no two ways about it in my book - the isolation and mapping of external drives/folder *outside container is nothing but effectively acting as a symbolic link.

[ghostwolf59]

btw, whats jail a reference to? typically it means prison, but i dont get the link to sonarr.

‘jail’ is commonly used to refer to whats normally is referred to as a ‘container’ on an enterprise servers my whole thread is based on the FreeNAS and linux

[rhom]

There’s no other way it can be described

a docker volume is fine. although i think most people just end up calling it a mapped volume if they were using docker containers

i understand what they are but not exactly how they work, i presume its a docker thing as the inside cant see them as a mount or link, it looks like a real directory to them

either way im trying to work out why you think a container would know the actual underlying host path that any of its volumes are mapped to? and even if it did, how is the receiving container supposed to get at the host path when there is potentially nothing inside the container to tell it how to do that?

eg, in my setup the docker run command for the sonarr container has --mount type=bind,source=/volume3/downloads,target=/downloads and --mount type=bind,source=/volume1/media,target=/media.

they are are on completely different host volumes so if i only mapped /media into sonarr, how is it going to access /volume3/downloads/...? its got no way to get at it.

neither /volume1 or /volume3 exist inside the container, the host volumes are not accessible from inside the container, and you cant have your container accessing host data it wasnt given, that would be a security nightmare. containers are isolated, they only see what you tell them to see.

this is why you have to map that /downloads volume into both containers.

[ghostwolf59]

im trying to work out why you think a container would know the actual underlying host path

Obviously the source volume & path pointed to need to point to the same physical location, but that dont mean the internal “symbolic” mapping needs to be - if A and B (two separate containers) points to C then C ought to be resolved for a process trying to interact cross containers. i,e Transmission is mapping its download directory to C but internally its called A - sonarr is relying on transmissions downloads directory, but shouldnt need to bother about what transmission called it - sonarr using B internally would still point to C - so C is the commons between containers/jails or whatever u want to call it.
It ought to be possible for the container to work out the underlying path to external source - hence referring to it within the container as a symbolic mapping.
Regardless of what each container actually calls is within its own container, the actual mapping to external source would be the same. Surely that ought to be possible - at least its a logical way to look at it and if the container app managed to resolve the physical path via internal mapping then the resolved external path could be used instead of forcing separate completely disconnected container configurations to be exact the same - In effect, the app should not care about the internals (that being /media, /download etc - it should take the /media, /download and resolved where it actually(!) is pointing to - if this was done, then the whole issue would disappear and everyone would be happy.
Again, I havent looked deep enough into how freenas jails works, but based on other experiences working with enterprise servers etc it ought to be possible.

[rhom]

It ought to be possible for the container to work out the underlying path to external source

except its not, containers are only meant to see what you tell them to see, nothing else.

hence referring to it within the container as a symbolic mapping.

except its not symbolically linked and you really shouldnt look at it that way.

the closest it comes to from a linux perspective is a hard linked directory (which you cant do in linux) but thats what it works like - and if you know how a hard linked file works then youll know why you cant resolve them back to a source

but based on other experiences working with enterprise servers etc it ought to be possible.

if you spin up containers for four different customers on the same host for a service you provide then theres no way in hell you want those containers to be able to poke around the host and potentially see the data for the other customers.

In effect, the app should not care about the internals

sort of defeats the whole purpose of containers then. they dont care about externals, they only see what you give them.

if this was done, then the whole issue would disappear and everyone would be happy.

you seem to have an expectation that everything it talks to is on the same host - what if its not?
what if transmission isnt even containerised but sonarr is, or vice versa? how is a container on host2 supposed to know how to get to host1/downloads when host1 gives that as a “resolved” path?
what if the host is not publicly accessible?

people could just do what they are meant to do and map in the volumes each container is required to access and then everyone is actually happy because its simple, secure, and it works. it mimics existing methods in that if you want your machine to access data on another machine you map a drive to it. docker just uses directories instead

if you dont like the way it currently works then youll have to take it up with docker/freenas, because its not an application level issue.

[ghostwolf59]

I dont think you understand what I am saying here - lots, and lots of statements from you that put a spin on things and dont relate to what I am on about - but lets leave it with that - dont think I will be able to reach you on this.
At least I now know what the service requires (logical or not) so I can get it up an running - there;s areas that could be looked at though

Its interesting that the internal mapping of the download client needs to be exact, while the mapping of the destination (completion) dont - instead you map a logical point that dont need to match the source name to where it physically resides - that works just fine - hence raising the issue why the download client location INTERNAL NAMING is important - if it points to the same location it ought to be ok

I leave it with that - cheers for taking the effort trying to explain things *not 100% convinced and I feel you missed several points of what I was eluding to)