Hi all, I’ll cut to the point: is anyone out there running a NAS with multiple users, and each user has their own media folders and files that belong to them, with share access to those files (samba), and separately is also running an instance of Immich (as its own user) that in some way has access to these files and folders, AND is able to upload new files, while maintaining the NAS user ownership/permissions on those files?

In my current setup, each user’s media files have permissions user:media 740 (so the “media” group has read access). The Immich user is in the media group. I then have the NAS files mapped as read-only, and added in Immich as external storage per user. This means I’m currently not uploading anything. (If I do, they get stored separately in Immich, not merged with the rest of the media files).

I could instead make the dir writable by the media group, map each NAS user’s media directories directly as their Immich upload location (and fix up the Immich file naming/organization so that it matches), but I would still have the problem that it would create new files as the Immich user on the NAS, not the specific user.

Is there a clever permissions solution here I’m missing, or is it a lost cause to try and have both coherent per-user permissions on the NAS/samba share, AND use Immich? I don’t really want a script that runs and chmods everything to user:media periodically. Feels hacky, and then Immich isn’t able to change/delete any files, but that might be the only solution…

  • PeriodicallyPedantic@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    3 hours ago

    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

    1. you need to be using Storage Templates.
    2. you’re willing to change the storage labels for all existing users
      • if not, then change the storage labels for all users to something temporary and run the migration job before you begin. You’ll change it back later.
    3. you’re willing to switch to NFS instead of samba, where each user gets their own share.
      • might not actually be necessary, but its what I use, so YMMV

    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 user
    

    There are 3 things about this setup:

    1. it does not scale automatically. this is fine as long as you don’t intend to be adding/removing users often.
    2. it is only saving the photos and videos. all thumbnails and transcoded videos, etc, get saved to ${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 the target: /data/library/user1 target you’ll also need a target: /data/thumbs/user1, target: /data/encoded-video/user1, etc.
    3. If there is already data at the 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/share
    

    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).

    • teawrecks@sopuli.xyzOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 hours ago

      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.