LEARN. PRACTICE. GROW.Confirm the destination before delivery
The lab starts with a local folder containing LOCAL-ONLY.txt. Querying findmnt for that path shows tmpfs. After mounting, the same query shows nfs4, source 127.0.0.1:/ and version 4.2. The local file disappears from view without being copied to the export. This sequence gives the learner a concrete observation for investigating jobs that turn green while the consumer receives nothing. In a fictional case, contain new runs and preserve inventory before mounting over an already used folder. Acceptance needs to confirm the relevant process’s filesystem because a familiar path or a configuration entry does not establish where bytes were written.
Interpret root mapping
The initial export allows writing, uses root_squash and explicitly sets anonymous UID and GID to 65534. A request made as UID 0 creates a server file with those values. When attempting to write inside a private root:root folder in mode 0700, the same client gets EACCES. That denial does not establish NAS unavailability: it identifies an operation the mapped identity cannot perform. The workshop asks for a short ticket explanation and an investigation proposal using the actual batch account. Repeating sudo on the client does not change the observed mapping. Removing the control before reproducing the correct identity can broaden privilege without resolving the intended functional requirement.
Compare normal identities and effective policy
A UID 20001 request creates a file retaining owner 20001. In that owner’s 0700 folder, writing succeeds for 20001 and fails for 20002. No domain accounts were created: the script uses synthetic numeric identifiers within one Linux system. The next phase unmounts the client, publishes a read-only export and mounts again; creation receives EROFS. Finally, all_squash with anonuid 25000 makes a request from 20001 create with UID 25000. Compare the three outcomes in a table. The exercise distinguishes retained identity, mapped identity and writing denied by export policy. Each change is confined to the disposable environment and accompanied by the effective export table.
Move from local results to enterprise acceptance
After unmounting, LOCAL-ONLY.txt reappears and the remote file remains on the server. The script removes the export, stops its services and checks the client mount and nfsd threads are absent. Both executions retain results, versions and script hash; the VM process was confirmed exited after poweroff. This evidence has limits: client and server share a kernel, sec=sys uses numeric identities, and there was no Kerberos, TLS, enterprise ACL or independent client. In a fictional project, turn the lab table into criteria for the actual platform with approved identities and allowed and denied operations. The local exercise prepares that decision but does not constitute enterprise architecture approval.
# Guarded execution INSIDE the prepared disposable RAM-root VM.
# Preparation and limits: content/labs/nas-nfs/README.txt
python3 /mnt/dr/run.py --output /mnt/dr/evidence.json
# Actual recorded scope: Linux NFSv4.2, sec=sys, guest loopback.
# No enterprise data, Kerberos, TLS or injected fault.A file created by root through the export receives UID 65534; another created by UID 20001 retains that identifier under root_squash.
Common pitfalls
Treating folder existence as a mount, granting no_root_squash before reproducing the correct account or using names as proof of numeric identity.
Related topics: Samba permissions and identity · Host rebuilding and migration
Diagnosis should connect path, mount, identity and operation. A writable export remains subject to permissions and mapping.
Reference: Linux NFS export policy and identity mapping · BigSavant NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior