Added a whole heap of knowledge files, including all SMSF docs. Modifed the email traige directios to tighten it the the inbox only.

2026-05-09 07:53:49 +10:00
parent a6ed815775
commit 85f78332d1
21 changed files with 379 additions and 10 deletions
@@ -0,0 +1,90 @@
+# 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**.