this post was submitted on 21 Sep 2025
103 points (100.0% liked)
Selfhosted
60409 readers
516 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You might be onto something, lidarr does have UMASK=002 setting in the .env file. I think the issue is when sabdnzbd puts the files and then lidarr can't read them, so what exactly is the expected permission setting then in this case? If I put it to 000 for lidarr, won't other services then be unable to add the files there?
I always feel so dumb when it comes to these things since in my head it's something that should be pretty straightforward and simple, why can't they all just use the same user and share the same permissions within this folder hierarchy...
Sab might have its own mask settings - it would be worth looking at. Same thing applies here - subtract the mask part from 7 to get the real permissions. In this case, mask 002 translates into 775. This gives the uid and gid that the container is running under (probably defined in a variable somewhere) Read/Write/Execute, but anyone else Read/Execute. The "anyone else" would just be any account on the system (regardless of access method) that didn't match on the actual uid or gid value.