ONTAP NFS Deep Dive: Versions, Export Policies, Kerberos & Performance

1. NFS protocol versions on ONTAP

ONTAP serves NFSv3, NFSv4.0, NFSv4.1 and NFSv4.2 simultaneously on the same SVM — the client negotiates. What each version gives you:

• NFSv3: stateless, simple, UDP or TCP, works everywhere. Still the default on many distros for mount -t nfs. No locking in the protocol itself (uses separate lock manager).
• NFSv4.0: stateful protocol with integrated locking and mount — a single TCP port (2049), no separate rpcbind/mountd needed. Requires the client and server to agree on an identity domain for user/group mapping.
• NFSv4.1: sessions (replay protection + connection recovery), server-side COPY, parallel NFS (pNFS) with FlexCache as the layout server. The recommended default for VMware and modern Linux.
• NFSv4.2: server-side copy offload, sparse file operations, lseek SEEK_HOLE — ONTAP supports it for NFSv4.2-aware clients.

Default enabled versions are viewable per SVM: vserver nfs show -vserver vs1 -fields v3-enabled,v4-enabled. Enable/disable per version:

vserver nfs modify -vserver vs1 -v3 enabled -v4.0 enabled \
  -v4.1 enabled -v4.2 enabled

# check what a client negotiated (per-connection)
vserver nfs connection show -vserver vs1 -instance | grep -iE "nfs version|remote"

2. NFS server setup

An SVM serves NFS once the protocol is enabled and export policies exist. Minimal setup:

vserver nfs create -vserver vs1

# NFSv4 requires an ID domain that matches the clients
vserver nfs modify -vserver vs1 -v4-id-domain example.com

# volume + junction
volume create -vserver vs1 -volume data -aggregate aggr1 -size 2t \
  -junction-path /data -security-style unix
volume mount -vserver vs1 -volume data -junction-path /data

# export policy (see section 3) then verify
vserver nfs show -vserver vs1 -instance

For NFSv4.x you also need a root volume junction for the pseudo-filesystem: ONTAP automatically exports the SVM root and the /data junction appears under it, so clients can mount svm:/data directly.

3. Export policies & rules

Export policies are the NFS equivalent of share ACLs: an ordered list of rules that decide who can mount what. Each volume/junction has one policy; rules match client IPs/hostnames and grant access with optional root-squash behavior.

vserver export-policy create -vserver vs1 -policy-name data_policy

vserver export-policy rule create -vserver vs1 -policy-name data_policy \
  -rule-index 1 -protocol nfs -clientmatch "10.0.0.0/8" \
  -rorule any -rwrule any -superuser any -allow-suid true

# rule fields that matter:
#   -clientmatch   CIDR / hostname / netgroup ("host1,host2", "*.corp")
#   -rorule/-rwrule  any | none | never | krb5 | krb5i | krb5p | nfs
#   -superuser      any | none | krb5* (root-squash behavior)
#   -allow-suid     honor setuid bits
#   -allow-dev      honor device nodes

# attach the policy to the volume
vserver export-policy apply -vserver vs1 -volume data \
  -policy-name data_policy

# order matters: rules are evaluated top-down, first match wins
vserver export-policy rule show -vserver vs1 -policy-name data_policy

Root squashing is controlled by -superuser: any lets NFS root act as Unix root (needed for some installers), none squashes root to nobody (the secure default for file shares). For Kerberos-only exports use -superuser krb5 etc. to force authenticated root.

4. NFSv4 domain & ID mapping

NFSv4 uses string identities (user@domain) instead of numeric UIDs. If the server's -v4-id-domain and the client's domain disagree, users are mapped to nobody and permissions mysteriously fail. Identity flow:

1. Client sends user@client-domain; ONTAP checks its own -v4-id-domain.
2. If domains match, ONTAP maps the name to a UID via its identity services: local files, LDAP/NIS, or name-mapping rules (vserver name-mapping).
3. If they don't match or lookup fails → nobody (UID 65534), which usually means "permission denied" at the file level.

vserver nfs show -vserver vs1 -fields v4-id-domain
vserver name-mapping show -vserver vs1 -direction win-unix
vserver name-mapping show -vserver vs1 -direction unix-win

# force a user lookup and see which UID ONTAP resolves
vserver name-mapping lookup -vserver vs1 -direction unix-win \
  -user-name "user@example.com"

For pure-Unix environments, keep the domain consistent everywhere (/etc/idmapd.conf Domain= on Linux clients) or set -v4-id-domain to match. With LDAP/NIS configured as the identity source, numeric UIDs resolve consistently across hosts.

5. Kerberos NFS (RPCSEC_GSS)

ONTAP supports sec=krb5, krb5i (integrity) and krb5p (privacy/encryption) flavors when the SVM is joined to AD and NFS Kerberos is configured. Setup steps:

# SVM must be joined to AD (vserver cifs create) or use a standalone Kerberos realm
vserver nfs modify -vserver vs1 -showmount enabled

# enable the security flavors at the protocol level
vserver nfs modify -vserver vs1 -v3-kerberos enabled \
  -v4-kerberos enabled

# then use them in export rules
vserver export-policy rule modify -vserver vs1 -policy-name data_policy \
  -rule-index 1 -rorule krb5p -rwrule krb5p -superuser krb5p

# client side
mount -t nfs4 -o sec=krb5p,vers=4.1 svm.example.com:/data /mnt/data

Kerberos failures are almost always: clock skew (NTP!), missing/expired keytab on the SVM, SPN mismatch, or the client not having a ticket (kinit). Check vserver nfs kerberos show -vserver vs1 -instance for the realm/keytab state.

6. Mount options that matter

VMware uses NFSv4.1 with its own mount settings (see ONTAP for VMware vSphere); AIX defaults to NFSv3 unless tuned.

7. Performance: sessions, trunking & tuning

• NFSv4.1 sessions: every mount gets a session with its own slot table — no more "stale file handle" storms on failover; connections survive LIF migration.
• Trunking: NFSv4.1 clients can open multiple connections to multiple LIFs (same SVM, same subnet) and trunk them — ONTAP supports this natively; verify with vserver nfs connection show.
• Read/write sizing: NFSv4.1 defaults to 1 MiB RPCs; for NFSv3 ensure clients use at least 64 KiB (rsize=65536,wsize=65536 on older clients).
• TCP settings: ONTAP tunes socket buffers automatically; the client's sunrpc.tcp_max_slot_table_entries and sunrpc.tcp_slot_table_entries on Linux can limit queue depth — raise them for 25/100GbE.
• CPU-bound workloads: NFSv4.1 with krb5p encryption is CPU-heavy on both sides; use krb5i (integrity only) when wire encryption isn't required, or terminate encryption at the client.
• Latency-sensitive apps: check the network path first — NFS is sensitive to RTT; see Performance Monitoring for latency isolation (protocol vs network vs disk).

8. Monitoring & operational commands

vserver nfs show -vserver vs1 -instance          # config + enabled versions
vserver nfs connection show -vserver vs1          # active client connections
vserver nfsstat -l -vserver vs1                   # per-LIF protocol counters
vserver export-policy show -vserver vs1           # policy inventory
vserver export-policy check-access -vserver vs1 \
  -volume data -client-ip 10.0.0.5 -auth-type sys \
  -protocol nfs -access-type read                # simulate an access decision

statistics show -vserver vs1 -object nfsv3 -counter * -sample-id 1
statistics show -vserver vs1 -object nfsv4 -counter * -sample-id 1

export-policy check-access is the single best triage command: it simulates exactly which rule fires for a given client and reports allow/deny + the rule index.

9. Troubleshooting matrix

Step-by-step diagnosis lives in the NFS troubleshooting runbook and NFSv4 ACL troubleshooting.

10. NFS vs SMB quick comparison

See NFS vs SMB vs S3 vs iSCSI vs FC vs NVMe for the full decision guide.