Selfhosted
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: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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!
view the rest of the comments
Preface
I got excited and didn't properly read your post before I wrote out a huge reply. I thought your problem was the per-user mapping to different locations on your NAS or to different shares, but its specifically file ownership.
whoops.
Leaving this here anyways, in case someone finds it helpful.
I kinda address file ownership at the end, but I don't think its really what you were looking for because it depends on every user having their own share.
Prerequisites
Configuration
Volumes
In docker, you'll need to set up an external NFS volume for every user. I use portainer to manage my docker stacks, and its pretty easy to set up NFS volumes. I'm not sure how to do it with raw docker, but I dont think its complicated.
Compose
in your docker compose files, include something like this
There are 3 things about this setup:
${UPLOAD_LOCATION}. For me this is fine, I dont want to pollute my NAS with a bunch of transient data, but if you want that info then for every user, in addition to thetarget: /data/library/user1target you'll also need atarget: /data/thumbs/user1,target: /data/encoded-video/user1, etc.target, when you mount this volume it will mask that data. This is why it is important that no users exist with that storage label prior to this change, else that data will get hidden.You may also want to add similar volumes for external libraries (I gave every user an external "archive" library for their old photos) like this:
and then you'll need to go and add that target as an external library in the admin setup.
and once immich allows sharing external libraries (or turning external libraries into sharable albums) I'll also include a volume for a shared archive.
Migrate
redeploy, change your user storage labels to match the targets, and run the migration job (or create the users with matching storage labels).
File ownership
I honestly don't think its important, as long as your user has full access to the files, its fine. But if you insist then you have a separate share for every user and set up the NFS server for that share to squash all to that share's user. Its a little less secure, but you'll only be allowing requests from that single IP, and there will only be a request from a single user from that server anyways.
Synology unfortunately doesn't support this, they only allow squashing to admin or guest (or disable squashing).
Squashing per-user is a blanket measure intended to default "public" users into a default access permission.
It is usable according to your layout, but this is effectively logical control preventing users from affecting files that aren't their own.
And if that is the goal, you might as well set this up as library access through immich.
Library access won't allow upload, this will.
My knowledge here isn't super deep, but it seems like you can do mapping per-share-per-ip, which means you can say "all file access coming from the immich host to this share will act as this user" which I think is fine if that share belongs to that user, and you don't have anything else coming from that host to that share which you want to act as a different user. Which are very big caveats.
This isn't right. https://docs.immich.app/administration/user-management/
I understand following op's pattern of wanting to set controls on underlying storage together with a share, but simply using immich's built-in storage labels is much easier.
Plus, each user can be assigned an NFS share to their individual files separate from immich's access requirements for storage. There is no need to make this a worse hodge-podge than op has already made it.
Sorry I misread when you said "library" for some reason I thought you meant "external library"
The problem that I'm trying to solve and I think OP is also trying to solve, is that they want the files to be on their NAS because it is high capacity, redundant, and backed up, but many users have access to the NAS, so they cannot rely on immich alone to provide access permissions, they need access permissions on the files themselves.
I solved this by having a separate share for every user, and then mounting that user's share on their library (storage label).
It sounds like OP wants a single share, so having correct file ownership is important to restrict file access to the correct users who are viewing the filesystem outside of immich.
Not sure what you mean by your last paragraph, how do you assign a share to individual files (assume you mean directories) outside of immich's need for storage?
Ah, gotchu. Carry on.
Thanks, yeah maybe not quite what I was asking for, but it does give me some stuff I didn't know about that I could consider.