So the utorrent and sonarr dockers both specify different directories within their docker space for the same downloads share. This normally would be fine, but the dockers communicate file paths with eachother for automatic import of downloaded media.
This causes permission errors within sonarr (and also radarr) because they connect to utorrent and see the file in /media/filename/file.ext and then try to import from /downloads/filename/file.ext. My solution is to add dummy values (another unrelated share) to /downloads in both sonarr and radarr and then use the add volume to add my utorrent downloads share as /media.
Is there any way to make this cleaner by altering the rockon jsons? The sonarr and radarr both specify /downloads and the utorrent specifies /media on their docker pages. Is it possible to not map volumes to /downloads and instead map them to /media on install? Or I guess flip that and change the utorrent to store in /downloads and never bind anything to /media?
My sonarr looks like this:
/downloads -> any random share
/media -> utorrent-downloads
/config -> sonarr-config
My utorrent is like this:
/media - > utorrent-downloads
/config -> utorrent-config
Additionally, is this change worth doing as it will force people to reinstall a lot and there isn’t really a clear way to communicate that in the UI (like an upadate required tag)?
Allow me to make a brief disclaimer first: my brain is getting tired today so I may have missed or misunderstood something in your setup.
I actually do not see anything wrong in the way you have setup your shares between Rock-ons so that they can communicate correctly. The root of the problem to me seems to reside in the following:
I believe these Rock-ons ask for a PID/GID at their install to help dealing with user permissions. Have you used the same user in all the Rock-ons you mentioned in your post? Is the share showing permission error owned by this user? Alternatively are the “Access” permissions allowing other users to read/write this share? (I’m referring to this part of the webUI)
Hope this helps, and again sorry if I’m missing something obvious in your message.
Thanks, then that almost rules that out. You could still try to temporarily set these shares to chmod 777 to double-check that it’s not related to that, but you shouldn’t need to, I believe.
I’m still confused by the following, however:
I’m confused by it because your original post does list this path among the shares added to the Sonarr Rock-on:
Would it be possible to share a screenshot of your settings pages for these rock-ons (clicking on the wrench icon)?
If I were to remove the added volume from sonarr called /media and just put the utorrent-downloads in the default share mapped to /downloads, the problem would resume.
Sorry for such a delay in my answer, things have been very busy for me lately.
So should I understand your issue is resolved? The screenshots you shared (thanks a lot!) fit with what should work and how I believe shares and storages should be mapped and configured.
I always keep my shares for the default mappings separate (as done in your screenshots) in order to avoid this kind of conflict. I’m unsure why it happens (somebody with this kind of expertise may be able enlighten us here), but I too noticed it when I first dabbled in this and decided to keep shares separate. It helped prevent this kind of behaviors, and also helps their management. If I uninstall a Rock-on, I can safely delete its share(s) without checking and worrying whether they are used by something else.
I’m sorry I couldn’t bring you more info about this, but I hope this helps.
Yes my issue is resolved with some share weirdness. I was just wondering if we could rewrite the .json of any of the rockons to fix this issue despite the fact that their docker containers require certain volumes called /downloads and /media? I just wanted it to be easier for others on install.
