NetApp ONTAP NFS Export Policy Configuration (CLI)

On NetApp ONTAP, every NFS volume export is governed by an export policy: a named collection of rules that decide which clients may mount the volume, from which IP ranges, and with what read/write/root privileges. Export policies sit between the SVM and the FlexVol, and getting them wrong is the most common reason a new NFS datastore or home directory mount fails with "permission denied" or "access denied by server". This article walks through creating an export policy, adding rules and attaching it to a volume with the ONTAP CLI.

All commands run from the cluster CLI in the admin privilege level and work on ONTAP 9.x. Nothing here is destructive, but the volume modify that attaches a policy takes effect immediately for new mounts, so a policy with a wrong -clientmatch can lock out existing clients that remount.

How Export Policy Evaluation Works

An export policy is a container of rules; a rule is a permission statement. ONTAP evaluates the rules of the policy attached to the volume, in rule-index order, and the first rule whose -clientmatch matches the client's IP address is the one that decides access. Nothing after that match is considered - there is no merging, no "best match wins", no fallthrough that adds permissions from a later rule.

Three layers matter when you debug a failed mount:

• The rule match - does any rule in the policy match this client IP? If none matches, the mount is denied outright.
• The access mode - read-only (-rorule), read-write (-rwrule) and root (-superuser) are evaluated separately for that same matched rule.
• The identity - a client reaching the volume with AUTH_SYS is checked against sys; a Kerberized client is checked against the krb5 variants. A rule that allows read-write for sys does not automatically allow a Kerberos-authenticated mount of the same volume.

That third layer catches people out in domains where NFS traffic was recently switched to Kerberos: the client IP still matches the rule, but the rule says sys,krb5 and the mount is being attempted with a machine credential ONTAP cannot verify. Checking which rule applied, and with which authentication flavour, is the whole of most export-policy troubleshooting.

Before You Start

Confirm the SVM exists and NFS is enabled on it (NFSv3/NFSv4 is enabled by default when the SVM is created for NAS, but verify with vserver nfs status). You also need a FlexVol to attach the policy to.

cluster1::> vserver show -fields vserver,type,state
cluster1::> vserver nfs status -vserver vs1
cluster1::> vserver show -vserver vs1 -fields allowed-protocols
cluster1::> volume show -vserver vs1 -fields volume,state,junction-path,policy

Also confirm the data LIFs are up and that the client's subnet can reach them - an export policy that is correct cannot save a mount whose NFS request never arrives at the SVM. Our ONTAP network configuration best practices article covers the LIF and routing prerequisites.

Create the Export Policy

vserver export-policy create -vserver vs1 -policyname nfs_policy

Policy names can be up to 256 characters. Every SVM has a default policy named default that allows no access — an explicit policy plus rules is required before any client can mount.

Create one policy per access pattern rather than one per volume: a shared policy for a standard read-only reference dataset, another for read-write application data, and a restrictive policy for volumes only the storage team touches. Naming them for the pattern (ro_reference, rw_app, admin_only) keeps the intent visible in volume show -fields policy output years later.

Add Rules to the Policy

A rule defines which clients match and what they may do. The example below lets hosts in 10.10.10.0/24 mount with read-write access, while the storage admin subnet 192.168.1.0/24 additionally gets superuser (root) access:

vserver export-policy rule create -vserver vs1 -policyname nfs_policy -ruleindex 1   -protocol nfs -clientmatch "10.10.10.0/24" -rorule sys,krb5 -rwrule sys,krb5 -superuser none
vserver export-policy rule create -vserver vs1 -policyname nfs_policy -ruleindex 2   -protocol nfs -clientmatch "192.168.1.0/24" -rorule sys -rwrule sys -superuser sys

Key rule parameters: -clientmatch accepts IP addresses, CIDR prefixes, netgroups (prefixed with @) or domain names; -rorule/-rwrule control read and read-write access with values sys (AUTH_SYS), krb5, krb5i, krb5p or none; -superuser decides whether root on the client maps to root (or an anonymous user) on the volume. Rules are evaluated in ruleindex order and the first match wins, so put specific ranges before broad ones.

The parameters worth knowing beyond that core:

• -ruleindex sets the evaluation order. Leave gaps (10, 20, 30) so a rule can be inserted later without renumbering the whole policy.
• -protocol accepts nfs, nfs3, nfs4 or cifs-related values, which matters when one volume serves both NFS and SMB and you want different access lists for each.
• -anonuid sets the UID used when a request arrives as a user ONTAP cannot map - the classic NFSv3 unmapped-tenant problem. Setting it to a meaningful local user is far better than leaving every unknown user as nobody.
• -allow-suid controls whether setuid and setgid bits are honoured on this export. Leave it false unless an application genuinely requires it; allowing setuid on a broadly reachable export is a security decision, not an operational one.
• -allow-dev controls creation of device files. Off by default and rarely needed.

Rule Order and the Default Policy

Order is the most frequent source of "it worked yesterday" reports. A policy whose first rule matches 0.0.0.0/0 with read-only access will never evaluate the specific read-write rule below it. When you add a rule, check the index and the match list together:

cluster1::> vserver export-policy rule show -vserver vs1 -policyname nfs_policy
cluster1::> vserver export-policy rule show -vserver vs1 -policyname nfs_policy -instance

The -instance form prints every parameter of each rule including anonuid, which is what you want when a mount is denied and the summary output looks correct. Note too that the SVM's built-in default policy is intentionally empty of allowing rules: a volume left without a policy assignment does not fall back to anything permissive.

Assign the Policy to a Volume

volume modify -vserver vs1 -volume vol1 -policy nfs_policy
volume show -vserver vs1 -volume vol1 -fields policy

The same policy can be shared by many volumes. If a volume currently has no policy assigned, ONTAP applies the SVM default policy (no access) — always assign a policy explicitly when you create the volume.

volume create -vserver vs1 -volume vol2 -aggregate aggr1 -size 500g -junction-path /vol2 -policy nfs_policy
volume modify -vserver vs1 -volume vol1 -policy nfs_policy -force

Including -policy at creation time avoids the window in which a new volume exists but is unmountable, and it documents intent in the create command that a support engineer reads later. Because policy changes take effect immediately, a client that already has a mount is not re-checked until it remounts or its lease expires - which is why a bad policy can appear to "work" during a test and fail the next morning.

Junctions, Mount Paths and Name Services

The export policy controls access; the junction path controls addressability. Volume vol1 with junction path /vol1 on SVM vs1 is mounted by clients as vs1:/vol1, and the export policy attached to the volume is what governs it - not the parent namespace volume.

cluster1::> volume show -vserver vs1 -fields volume,junction-path,junction-active
cluster1::> vserver show -vserver vs1 -fields nis-domain,ldap-servers

Name services matter when the export uses netgroups or hostnames instead of CIDR ranges: an export referencing @admins resolves through the SVM's LDAP, NIS or local netgroup configuration, and a broken name service fails closed - clients that should match do not. CIDR-based matches have no such dependency and are the safer default in environments where the directory service is also the thing being repaired.

Verification and Common Failures

vserver export-policy rule show -vserver vs1 -policyname nfs_policy
vserver export-policy check-export -vserver vs1 -path /vol1 -client 10.10.10.50
vserver nfs status

export-policy check-export is the fastest way to see which rule would apply to a given client. Typical mount failures trace to: no rule matching the client subnet, -superuser none blocking root mounts, NFS disabled on the SVM, or a junction-path mistake in the mount string. If name resolution is involved, check the name-service configuration (LDAP/NSDB) — our ONTAP network configuration best practices article covers the LIF and routing prerequisites, and ONTAP SnapMirror shows the CLI style for the rest of the data-protection stack.

The check-export output is the single most useful line in this whole procedure: it returns the matched rule index, or reports that no rule matched. Run it from the cluster for the exact client IP that is failing, before you change anything.

Testing From the Client

Once check-export says the right rule applies, verify from the client side - the two halves of an NFS problem look identical in the error message:

# showmount -e 10.10.10.11
Export list for 10.10.10.11:
/vol1 10.10.10.0/24

# mount -t nfs -o vers=3 10.10.10.11:/vol1 /mnt/vol1
# mount -t nfs -o vers=4.1 10.10.10.11:/vol1 /mnt/vol1
# nfsstat -m
# df -h /mnt/vol1

If showmount -e lists the export but the mount fails, the problem is authentication or the rule's access mode. If the export is not listed at all, no rule matches the client and nothing about Kerberos or root mapping is relevant yet. Testing NFSv3 and NFSv4.1 separately is worth the extra minute, because the two versions resolve identity differently and a client can succeed on one and fail on the other. For persistent mounts, add the entry to /etc/fstab with _netdev and matching vers= after the manual mount succeeds.

Securing the Export: Kerberos and Root Mapping

Three settings cover most of the security surface of an NFS export:

• Authentication flavour. sys trusts whatever the client claims. krb5 authenticates the user, krb5i adds integrity, krb5p adds privacy. Set krb5p where traffic crosses untrusted networks, and confirm the SVM has a Kerberos interface configured before clients are switched over.
• Superuser mapping. -superuser none prevents a compromised client from rewriting ownership across the export as root; use sys only for the narrow admin subnet.
• Client match breadth. Prefer per-subnet clients over 0.0.0.0/0. A broad read-write rule is the difference between an export and an open share.

Where a volume must serve both NFS and SMB, remember the two protocols use different mechanisms - export policy rules for NFS, share ACLs for SMB - and permissive settings in one do not grant access in the other, but permissive settings in either widen what an attacker on that network path can reach.

Frequently Asked Questions

Why does the mount work as root but fail as a normal user? The matched rule's -superuser setting is usually none or the rule grants only -rorule. Check check-export and then the file-level permissions on the volume.

Can I attach one policy to volumes in different SVMs? No. Export policies are per-SVM objects; create the same rule set in each SVM rather than copying between them.

Does changing a policy drop existing mounts? Not immediately - established mounts keep working until the client remounts or the lease expires, which is why policy mistakes surface later.

Do I need a policy for NFSv4.1 with pNFS? Yes. The export policy governs all NFS versions; pNFS adds data-server handling but does not bypass the rule match. For the wider protocol picture, see FC vs iSCSI vs NVMe-oF, and for day-to-day CLI patterns the ONTAP CLI cheat sheet.

原文链接：https://docs.netapp.com/us-en/ontap/nfs-config/create-export-policy-task.html