91 lines
3.9 KiB
Markdown
91 lines
3.9 KiB
Markdown
# 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**.
|