Storage Admin HubConfiguration · Protection · Recovery
All guides/NAS
NAS · ONTAP 9

Configure NFS access end to end

SVM service, export policy, volume junction, and client mount.

Scenario

Example: Linux client 192.0.2.45 mounts 192.0.2.30:/projects at /mnt/projects. Replace test addresses and use the security flavor required by your environment.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Prepare identities and network

  1. Ensure the NFS data LIF is reachable from the client and the SVM has NFS enabled. Decide NFSv3 or NFSv4.x, name services, UID/GID behavior, Kerberos if used, and root access policy.
  2. Create an export policy for only the required client or subnet. Set read-only, read-write, and superuser security deliberately; a matching client IP alone does not imply write access.
Read-only checks 
vserver nfs show
network interface show
vserver export-policy rule show

2. Create access path

  1. Create the volume on the correct SVM and mount it at a junction such as /projects. Associate the intended export policy with the volume. Ensure traversal through the SVM root and parent junctions is permitted.
  2. In System Manager, review Storage > Volumes and the volume export settings. On the client, mount the exact data LIF or DNS name and junction path using the approved NFS version.
Example Linux client commands 
sudo mkdir -p /mnt/projects
sudo mount -t nfs -o vers=4.1 192.0.2.30:/projects /mnt/projects
mount | grep /mnt/projects

Worked CLI example: allow one test client

  1. Assume NFS is enabled on svm_prod and the volume exists at /projects. Create a policy for the one test client. AUTH_SYS in this example is appropriate only when the environment accepts that security model.
  2. Associate the policy with the test volume, verify the rule and mount from 192.0.2.45. Root access is not granted by this example; use a named test UID for write validation.
Example change commands · review before running 
vserver export-policy create -vserver svm_prod -policyname exp_projects
vserver export-policy rule create -vserver svm_prod -policyname exp_projects -ruleindex 1 -protocol nfs -clientmatch 192.0.2.45 -rorule sys -rwrule sys -superuser none -anon 65534
volume modify -vserver svm_prod -volume vol_projects -policy exp_projects
vserver export-policy rule show -vserver svm_prod -policyname exp_projects
Verify

Only the intended client matches rule 1 and a test user can perform the approved read/write operations.

3. Test permissions and recover failures

  1. From a permitted test account, create and read a file, verify ownership, and remove only the test file. Check both read and write behavior.
  2. For access denied: check export policy association, ordered rule matching, protocol version, security flavor, SVM root export traversal, UNIX mode bits/ACLs, and identity mapping. For timeout: check LIF, route and firewall before permissions.
Verify

An authorized client mounts and reads/writes as intended; an unauthorized client is denied.

If validation fails

  1. Timeout before mount negotiation usually points to LIF, network, routing or firewall. Test the exact client-to-LIF path before editing export rules.
  2. Access denied after reaching the server points to export-policy match, security flavor, root traversal or UNIX identity. Inspect the rule index and the client address actually seen by ONTAP.
  3. A successful mount with failed writes often means read-only export permission or UNIX file permissions; test with the intended UID and GID.
Verify

Re-run the original validation and record the observed result, exact error, time, and corrective action.

NetApp references