Knowledge/chat-topics/shared-linux-users-truenas-store.md

Shared Linux Users + TrueNAS Remote Store

Checkpoint from Michael, 2026-05-08.

Scenario

• Two local Linux user accounts.
• One remote TrueNAS/NAS storage location.
• Both local users need equal/shared access to the same remote store.
• Michael is comfortable with Linux and already has many CIFS/SMB shares.
• Open question: continue with CIFS/SMB, or consider NFS.

Initial opinion / direction

For a Linux-to-TrueNAS shared workspace where both local Linux users need equal access, the cleanest model is usually:

1. Prefer NFSv4 if it is mostly Linux clients

   • Better Unix permission semantics than SMB.
   • Cleaner UID/GID ownership model.
   • Less friction with executable bits, symlinks, POSIX-style permissions, rsync, shell workflows, dev/project files.
   • TrueNAS handles NFS well.

2. Use SMB/CIFS if Windows/macOS/user-facing mixed access matters

   • Easier cross-platform browsing.
   • TrueNAS SMB ACL model can be excellent, but Linux client UID/GID mapping can get annoying.
   • Fine for documents/media/general shares; less ideal for Linux-native project/workspace semantics.

3. Best shared-access pattern

   • Create a shared group on Linux, e.g. nasstore.
   • Add both local users to that group.
   • Ensure files/directories are group-writable.
   • Use setgid directories so new files inherit the shared group.
   • Use a sane umask/default ACL so both users retain write access.

Likely recommended NFS setup

TrueNAS side

• Dataset owned by a shared UID/GID strategy, or use NFS mapall/maproot carefully.
• Export via NFSv4.
• If practical, align numeric GID between TrueNAS and Linux clients for the shared group.
• Dataset permissions:
  • owner: service/admin user or root as appropriate
  • group: shared group, e.g. nasstore
  • mode: directories 2775, files 664
  • default ACL or inherited permissions to preserve group-write.

Linux client side

• Create shared group on each Linux client with same numeric GID if possible:
  • sudo groupadd -g <gid> nasstore
  • sudo usermod -aG nasstore user1
  • sudo usermod -aG nasstore user2
• Mount NFS share at stable path, e.g. /mnt/nasstore or /srv/nasstore.
• Mount via /etc/fstab with systemd automount to avoid boot hangs:
  • x-systemd.automount,_netdev,noatime,nfsvers=4.2
• Set directory inheritance:
  • chmod 2775 /mnt/nasstore
  • optional default ACL: setfacl -d -m g:nasstore:rwx /mnt/nasstore
  • optional actual ACL: setfacl -m g:nasstore:rwx /mnt/nasstore

CIFS alternative notes

If sticking with SMB/CIFS:

• Use one TrueNAS SMB share with a NAS-side group allowed full control.
• On Linux, mount with either:
  • a shared local group via gid=nasstore,file_mode=0664,dir_mode=2775, or
  • per-user credentials plus SMB ACLs if accountability matters.
• Common fstab options to revisit:
  • credentials=/root/.smbcredentials-...
  • uid= / gid= depending on whether one local owner or shared group is desired
  • forceuid,forcegid only if deliberately flattening ownership
  • file_mode=0664,dir_mode=2775,noperm,_netdev,x-systemd.automount
• SMB is acceptable, but more likely to produce Linux permission weirdness than NFS.

Key decision to make tomorrow

Ask Michael:

1. Is this store Linux-only, or do Windows/macOS clients also need first-class access?
2. Do the two local Linux accounts need separate audit identity on the NAS, or is shared write access enough?
3. Is the data mostly documents/media, or Linux project/dev files with symlinks/executable bits?
4. Does the NAS already have a dataset/group/ACL scheme we should preserve?

Provisional recommendation

If this is primarily Linux users sharing a TrueNAS-backed workspace: use NFSv4 with aligned shared group IDs and setgid/default ACLs.

If the share must remain friendly to Windows/macOS and already exists as SMB: keep SMB, but mount it as a shared local group with explicit gid, file_mode, dir_mode, and automount options.