search

RandomNinjaAtk / docker-lidarr-extended

lidarr-extended :: Lidarr application packaged with multiple scripts to provide additional functionality
GNU General Public License v3.0
275 stars 24 forks source link

If you remove /downloads and replace it with /lidarr-extended as the volume to mount, it would have less likelihood of interfering with anyone who already has /downloads taken in their containers. If folks are reporting errors with abc:abc this could be from using something like a NAS and finding that chown isn't going to cooperate under certain circumstances. Looking it over, is the chown even necessary? Even with chown errors via a NAS mountpoint, things still import and are removed -- so it's something to consider. #16

Closed telix5000 closed 2 years ago

RandomNinjaAtk commented 2 years ago

This is not needed, the volume can be mapped anywhere you want even with the name /downloads for the internal directory/volume mapping. You should read up on docker volumes to get a better understanding of the core concepts.

telix5000 commented 2 years ago

You’re missing the point. The only important folder is the sub folder essentially. It doesn’t matter where one maps /downloads to, the issue is it is a commonly used and often taken name. Not everyone wants to re-architect around something taking up /downloads or share it, when the chown commands do not play all that nice with different mount points if /downloads was previously defined. It would be advisable and in the best interest of this project, to move from using /downloads and just essentially use /lidarr-extended. The alternative is to omit the chown abc:abc’s as it doesn’t seem to really do anything — because even after sifting through logs where it errors out, the script still did what it was intended to. So in my situation, as everything was fine before — everything else had to change from /downloads to something else like /data and now /downloads sits on a local SSD. This is because the clients still pull data into their respective downloads and the manager, Lidarr polls from there via the mount to import back in; when really instead of having a dependency on /downloads and just reserving the name space for the script payload is more optimal.

Sent from my iPhone

On Jul 15, 2022, at 2:37 AM, RandomNinjaAtk @.***> wrote:

 Closed #16.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

RandomNinjaAtk commented 2 years ago

Your missing the point! There is no dependency, you don't understand the fundamentals and core concepts on how docker volumes work. I suggest you do some reading. That is all...

Edit: I updated the readme to try to make it more clear... https://github.com/RandomNinjaAtk/docker-lidarr-extended#usage