AFF/FAS FlexVol · NFSv4.1 with AUTH_SYS · Linux client
Illustrative lab: svm_prod already exists with an NFS data LIF at 192.0.2.30. Client 192.0.2.45 needs read/write access to /projects. The application runs as UID 2001 and GID 2001. This example uses AUTH_SYS on a controlled network; a Kerberos deployment needs a separate identity and keytab design.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Define the identity and namespace before provisioning
NFS access has two separate gates: the export policy determines which client and security flavor may reach the path; file ownership and permissions determine what the process may do inside it. A successful mount proves neither write access nor correct application identity. Keep the client address, user identity and junction path together in the change record.
| Item | Example | Why it matters |
|---|---|---|
| SVM and volume | svm_prod / vol_projects | The policy and junction belong to this SVM. |
| Client / data LIF | 192.0.2.45 / 192.0.2.30 | Rules must match the client address ONTAP actually sees. |
| Namespace | /projects under the SVM root | Each parent path needs traversal access. |
| Application identity | UID 2001, GID 2001 | AUTH_SYS uses the client-provided numeric identity. |
| Permission goal | One client, named user, read/write | Root access is a separate decision. |
- On Linux, run id for the application account and record its numeric UID and groups. Compare them with your directory service or local account standard. Decide whether root must be squashed; this example keeps root mapped to an anonymous identity.
- On ONTAP, check that NFSv4.1 is enabled and the data LIF is operational. Check the planned aggregate and SVM root volume. Inspect existing policies before creating anything; do not replace a shared policy used by other applications.
vserver nfs show -vserver svm_prod
network interface show -vserver svm_prod
volume show -vserver svm_prod -fields junction-path,policy,security-style
# Linux: substitute the actual application user
id appuserThe chosen protocol, numeric identity, client route and existing root traversal policy are recorded.
02Create a narrow policy and a mounted data volume
- Create a dedicated export policy for the test client. The read and write rules both allow sys, while superuser none preserves root squashing. In production, select the security flavor from the approved security design.
- Create a UNIX-security volume on an aggregate with enough physical headroom. Set the junction path and export policy explicitly. A 100 GB volume is a lab size, not a capacity recommendation.
- Inspect the SVM root policy independently. Permit the same client to traverse the root and any parent volumes using the minimum necessary read access. Do not turn a shared root export into a broad read/write export.
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
volume create -vserver svm_prod -volume vol_projects -aggregate aggr_data -size 100GB -security-style unix -junction-path /projects -policy exp_projects
vserver export-policy rule show -vserver svm_prod -policyname exp_projects
volume show -vserver svm_prod -volume vol_projectsThe volume is online at /projects; only the intended client matches the data export rule. Root traversal has been checked separately.
03Evaluate export access before touching the client
The check-access command walks the namespace. Read the result for every path component, not only the last row. If the data export allows writes but the root path denies traversal, a client still cannot reach the volume. This check evaluates export access; it does not replace a file permission test.
| Illustrative result | Interpretation | Next action |
|---|---|---|
| Root: read; projects: read-write | Namespace traversal and export authorization are present. | Test as the application UID. |
| Root: denied / no matching rule | Failure occurs before the data export. | Inspect the policy assigned to the SVM root. |
| Projects: read only | Mount may succeed; a write can fail. | Inspect rwrule and security flavor. |
| No matching data rule | Client IP, protocol or authentication does not match. | Compare observed client address with clientmatch. |
vserver export-policy check-access -vserver svm_prod -client-ip 192.0.2.45 -volume vol_projects -authentication-method sys -protocol nfs4 -access-type read-write04Mount and test with the real application identity
- Install the distribution-supported NFS client tools. Create a temporary mount point and mount with an explicit version. Avoid adding an unverified entry to /etc/fstab during the first test.
- Inspect the mounted protocol and options. Prepare a test subdirectory owned by the intended UID/GID using the authorized storage or application administration process. Root squashing can prevent a client root account from changing server-side ownership.
- Run the write/read/delete test as appuser. Give the test file a recognizable name and remove only that file. If the test passes, apply the approved persistent mount settings and rehearse a reboot in the lab.
sudo mkdir -p /mnt/projects
sudo mount -t nfs -o vers=4.1,sec=sys 192.0.2.30:/projects /mnt/projects
findmnt /mnt/projects
sudo -u appuser sh -c 'printf "NFS validation\n" > /mnt/projects/validation.txt'
sudo -u appuser cat /mnt/projects/validation.txt
sudo -u appuser rm /mnt/projects/validation.txtThe application identity can create, read and delete its test file; an out-of-scope client remains denied.
05Use the symptom to choose the next check
Example diagnosis: client .45 mounts successfully, check-access permits read/write, and a file is owned by UID 3001 with mode 0640. appuser is UID 2001 and is not in the owning group. Widening clientmatch would change nothing. Correct the approved owner/group or ACL on the target directory, then repeat the exact failing operation.
| Symptom | Targeted check | Useful conclusion |
|---|---|---|
| Mount times out | Route, data LIF state, firewall and TCP 2049 for this v4.1 example | Permissions cannot fix a transport timeout. |
| Mount returns access denied | check-access, junction and parent policies | Locate the first denied namespace component. |
| Mount succeeds; appuser cannot write | id, numeric ownership, mode bits/ACL and read-write export | Separate export access from file authorization. |
| Root denied but appuser works | Superuser rule and anonymous mapping | This can be the intended root-squash behavior. |
| Wrong names or nobody ownership | NFSv4 domain and name-service configuration | Verify identity consistency before changing ACLs. |
06Roll back the pilot and preserve useful evidence
- If the pilot fails, stop the test application and unmount the temporary client mount. Restore only the policy association or mount configuration changed for this pilot. Keep the volume if it contains data needed for diagnosis.
- Before removing an export rule, confirm it is not being used by another approved client. Before deleting a volume, prove that it contains only disposable lab data and obtain the applicable deletion authorization.
- Record the actual client address, mount options, UID/GID, export evaluation, directory permissions and validation result. Those details make a future access incident reproducible.
sudo umount /mnt/projects
vserver export-policy rule show -vserver svm_prod -policyname exp_projects
volume show -vserver svm_prod -volume vol_projectsThe rollback affects only the pilot, and the reason for the failed operation is documented.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.