mirror of
https://github.com/RandomNinjaAtk/arr-scripts.git
synced 2026-03-02 22:57:35 -05:00
[BUG] - LIDARR - Changing permissions of beets files to those other than the container user #138
Labels
No labels
Needs Triage
Not Reproducible
Upstream Issue
User Error
bug
documentation
enhancement
good first issue
help wanted
invalid
lidarr
lidarr
question
radarr
readarr
sabnzbd
sonarr
synology (host)
unraid (host)
waiting for logs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/arr-scripts#138
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @krankydonkey on GitHub (Apr 7, 2024).
Application
Lidarr
Host platform
podman on ubuntu server 22.04
Script
BeetsTagger.bash
ArtworkExtractor.bash
LyricExtractor.bash
Script Version
latest
Describe the bug
I have created a secondary user and group on Ubuntu called media (1001:1001). The lidarr container is run with the command below, and sets the PUID and PGID environment variables to the media user/group. Lidarr creates its standard config files with these owners, but all files created by download script and all extended scripts still have owner 1000:1000. I have to chown them to get them to work. However, when downloading new content the scripts will keep changing the beets-library.blb and beets.log files to 1000:1000, and then lidarr shows errors:
For each of the scripts listed above
Podman run command:
podman run
--name=lidarr
--detach
-e PUID=$MEDIA_UID
-e PGID=$MEDIA_GID
-e UMASK=002
-e TZ=Australia/Brisbane
-p 8686:8686
-v /etc/localtime:/etc/localtime:ro
-v /nas/apps/lidarr/config:/config
-v /nas/apps/lidarr/custom-services.d:/custom-services.d
-v /nas/apps/lidarr/custom-cont-init.d:/custom-cont-init.d
-v /nas/data:/data
linuxserver/lidarr:latest
@hockeygoalie35 commented on GitHub (Apr 8, 2024):
Have you tried starting the container as 1001 (the docker run command)?
On Sun, Apr 7, 2024 at 11:49 PM krankydonkey @.***>
wrote:
@hockeygoalie35 commented on GitHub (Apr 8, 2024):
Actually you know what, try adding —user 1001:1001. The environmental variables are just for LiDARR, maybe not the base OS running in the container.
@krankydonkey commented on GitHub (Apr 8, 2024):
Unfortunately that seems to break lidarr. To get the initial lidarr environment working with the media user, I had to chown the config and data directories with:
podman unshare chown -R $MEDIA_UID:$MEDIA_GID /nas
the files show up with permissions of 101000:101000 when I run ls -l as the default user
@hockeygoalie35 commented on GitHub (Apr 8, 2024):
Sorry just to confirm, are you executing the docker run command with the default user, or the media user?
@PapaBearDoes commented on GitHub (Apr 19, 2024):
I can confirm that "user: 1001:1001" does indeed break the Lidarr container (I use Linuxserver.io's container). I didn't grab the error specifically when it occurred, sorry for that.
I was getting file permissions errors, but I don't specifically remember what exactly was occurring, just that I attempted to use the "user: 1001:1001" thinking it might help.
In Lidarr under Settings -> Media Management -> Permissions you can set the CHOWN group (I ultimately used the group number (1001) instead of the name as the name was causing other issues).
@RandomNinjaAtk commented on GitHub (Jun 2, 2024):
The files in the final destination are managed by lidarr and permissions/ownership would be set by the application.
All other files are just a means of doing the work and are mostly meant to be temporary at best… So if the files do not have the correct permission in the final destination, which is managed by lidarr, it would either be a user configuration error or upstream issue…