

Hmmmm that’s a good point.
I still wouldn’t count that as every day life because you’re not physically interacting with the satellite or submarine internet cables, even if you’re interacting with the effects of their existence.
But now I have to justify why my stance of “being physically near but still unable to see or touch directly” (as an internal mechanism of something) is any more “everyday life”. It feels like an internal mechanism counts as just as every-day as the thing its a part of, but is it really?
I don’t have a solid justification. It just feels different to me.







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
services: immich-server: # ... volumes: - ${UPLOAD_LOCATION}:/data - /etc/localtime:/etc/localtime:ro - type: volume source: user1-share target: /data/library/user1-intended-storage-label volume: subpath: path/to/photos/in/user1/share - type: volume source: user2-share target: /data/library/user2-intended-storage-label volume: subpath: path/to/photos/in/user2/share # and so on for every user # ... volumes: model-cache: user1-share: external: true user2-share: external: true # and so on for every userThere 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:
- type: volume source: user1-share target: /unique/path/to/this/users/archive volume: subpath: path/to/photo/archive/on/shareand 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).