SMB plus Immich (App) access to a dataset

TrueNAS General
1

I asked Claude but want to run this by actual humans.

I have a WinShare SMB dataset (owned by smb:x:3000:3000) that I also want to allow access to an Immich App (apps:x:568:568).

Claude recognized the dilemma and seemed to be waffling on the solution. Tinkering with POSIX vs NFSv4 ACL types. Also when POSIX tinkering with ownership by Apps vs SMB.

That’s the answer. smb is UID 3000 on the TrueNAS host OS — so the 3000:3001 you saw earlier was actually the smb user owning the dataset, not Immich’s container UID.

So the original ownership of smb:smb (3000:3000) was correct for SMB access. We need to revert what we did.

Restore Correct Ownership

bash

sudo chown -R smb:smb /mnt/Enterprise_Disks/Win-Share
sudo chmod -R 775 /mnt/Enterprise_Disks/Win-Share
sudo find /mnt/Enterprise_Disks/Win-Share -type f -exec chmod 664 {} \;

Verify

bash

ls -lan /mnt/Enterprise_Disks/Win-Share

You should see 3000:3000 back on the files.

Now Back to the Immich Question

With smb:smb (3000:3000) owning the dataset, we need to confirm what UID Immich’s container actually runs as so we know if it can read/write the share. …
Since it’s the official TrueNAS community app, Immich’s container UID is well documented. Run this to check what UID Immich is actually running as inside its container:

bash

sudo k3s kubectl get pods -n ix-immich

That will show you the Immich pod names, then run:

bash

sudo k3s kubectl exec -n ix-immich <pod-name> -- id

Replace <pod-name> with the actual pod name from the first command (likely something like immich-server-xxxxxxxxx).

This will tell us the exact UID:GID Immich uses inside the container so we know what the dataset ownership needs to be to satisfy both Immich and SMB simultaneously.

What have you all done in this regard?

2

Can we use group permission to get both access?

1:17 PM

Claude responded: Yes, that’s a much cleaner solution than a cron job.

Yes, that’s a much cleaner solution than a cron job. The idea is:

  1. Add smb user to the apps group (or vice versa)

  2. Set dataset ownership to apps:apps with group write (775)

  3. SMB writes as smb user, but since smb is in the apps group it has full read/write

  4. Immich (running as apps) owns the files and has full access

Check if it’s possible first

bash

sudo usermod -aG apps smb

Then verify:

bash

id smb

You should see apps (568) listed in smb’s groups.

Then make sure the dataset is set correctly:

bash

sudo chown -R apps:apps /mnt/Enterprise_Disks/Win-Share
sudo chmod -R 775 /mnt/Enterprise_Disks/Win-Share
sudo find /mnt/Enterprise_Disks/Win-Share -type f -exec chmod 664 {} \;

The 775 means:

  • Owner (apps) → rwx

  • Group (apps) → rwx — smb user inherits this via group membership

  • Other → rx

This way files written by SMB land as smb user but are group-writable, and Immich can read/write everything. No cron job needed. Want to try it?

3

That looks mostly wrong and none of that needs to be done via shell. We have a UI / API for permissions management. This simplest way in this case to grant permissions would be to simply add two entries to the NFSv4/SMB ACL.

builtin_users (group of which your smb user is a member) – MODIFY or FULL_CONTROL
apps (group 568) – MODIFY or FULL_CONTROL

No need to chown / chmod / etc.

1 Like
4

Thank you. I will give that a go.