LEARN. PRACTICE. GROW.Concept and mechanism
Authenticating a client, preventing modification in transit, and hiding content are distinct properties. Among the presented NFS Kerberos security flavors, krb5 handles authentication, krb5i adds integrity, and krb5p provides privacy protection. Implementation and configuration on both sides must be compatible. Other transport-protection methods exist, but encryption should not be inferred from UID/GID or permitted access. In SMB, signing protects integrity; encryption protects privacy and integrity. A configuration observation showing signing does not itself prove that network observers cannot read transmitted payload. State the required property and gather evidence of the protection actually negotiated.
Guided application
In the Samba SMB3-over-TCP examples, desired and required are not equivalent. Requiring encryption can reject incompatible clients, and global negotiation must also allow the intended configuration. Do not declare success after a silent downgrade. Confirm the cause and prepare a compatible client. Another decision affects persistence: on a Linux export, async permits replying before changes reach stable storage, while sync waits for that condition. Reduced latency can therefore change risk under an unclean server failure. In a fictional project, communicate this trade-off with application owners and validate recovery instead of treating every reply as proof of identical durability.
A faster async reply does not demonstrate the same acknowledged persistence as sync.
Common pitfalls
Signing as privacy; desired as required; at-rest protection as transport protection; reply as universal persistence.
Related topics: Shares and mounting · Identity and permissions · Caching, timeouts, and uncertainty
Define the required guarantee and confirm the effective mechanism providing it.
Reference: Linux NFS export policy and identity mapping · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior