NFSv4.1 Kerberos Mount Failures After DNS Change
An ONTAP 9.12 SVM named nfs_svm exports NFSv4.1 with Kerberos 5 privacy (krb5p) to Linux clients in a Windows AD environment. The SVM has a data LIF on 10.1.0.50 and uses AD DNS. After a DNS zone change, existing clients that mount by FQDN still work, but new clients on the 10.1.0.0/24 subnet fail to mount with 'Permission denied'. The new clients can ping the LIF and resolve the SVM name. The export policy has a rule for 10.0.0.0/24 with sec=krb5p but no rule for 10.1.0.0/24. The SVM keytab exists and NTP is synchronized. The team wants to know whether this is a Kerberos problem, an export policy problem, or both, and how to diagnose it without guessing.
1. List the most likely causes and the evidence you would collect before changing anything.
Read the worked answer
There are two separate likely causes. First, the export policy has no rule for 10.1.0.0/24, so NFSv4.1 access from the new subnet is denied regardless of Kerberos. Second, the new LIF's 10.1.0.50 address may lack a PTR record in DNS. Kerberos clients that mount by IP address need reverse resolution to map the address to the service principal used by the SVM; without it, the mount can fail with permission or principal errors.
Collect evidence: vserver export-policy rule show for the SVM; vserver services name-service dns check; client kinit and mount -vvv output; kvno nfs/<svm-fqdn>; and a packet trace on the SVM during a failed mount. Check event logs for Kerberos or access-denied messages. Confirm whether the client is mounting by IP or FQDN. Do not assume the keytab is the problem just because Kerberos is in use.
2. State the fix and the validation steps that prove both NFS and Kerberos access work for the new subnet.
Read the worked answer
Add an export policy rule for 10.1.0.0/24 with the same access and security settings as the working subnet, including sec=krb5p and the correct read-write and root access settings. Then create or correct the DNS PTR record for 10.1.0.50 and verify forward and reverse resolution. Ensure the SVM's Kerberos service principal is present and that clients can obtain a ticket for nfs/nfs_svm.example.com.
Validate from a new client: run kinit, confirm klist shows a valid ticket, mount by FQDN with -o sec=krb5p,vers=4.1, create and read a test file, and verify the identity mapping with id or an ONTAP access check. Repeat the mount by IP to confirm reverse resolution is fixed. Check the SVM event log and packet trace for clean Kerberos negotiation and no access-denied errors before closing the change.