# 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**.