NFS or SMB client cannot access data

01Scope the symptom

1. Record client address, user identity, SVM/data LIF, exact path/share, protocol version, error text, first failure time, and whether other clients work.
2. Resolve the name from the client and connect to the data LIF. If connection times out, inspect VLAN, route, firewall, port and LIF. If connection succeeds but access is denied, inspect policy and identity.

network interface show
network route show
event log show -severity ERROR

02NFS branch

1. Confirm the junction path is mounted and each parent path can be traversed. Inspect export policy on the volume and rule order, client match, protocol, read/write security, superuser treatment, and UNIX ownership.
2. Test a single authorized client using the exact LIF and path. Do not broaden the rule to all clients merely as a diagnostic.

vserver nfs show
volume show -fields junction-path,policy
vserver export-policy rule show

03SMB branch

1. Confirm the SMB server is joined to AD, DNS and time are healthy, and the share points to the expected volume path.
2. Inspect share permissions and file-system ACLs with the user token and group memberships. Test another known-good user to isolate identity versus share-wide failure.

vserver cifs show
vserver cifs share show

04Worked comparison: one client fails while a peer works

Example NFS case: two clients use the same export, but the failing client is behind a new routed/NAT path. Its address as seen by ONTAP no longer matches the narrow export rule. Once that address is established, the owner can approve a targeted network or export change. Copying a wide subnet rule from a working application would hide the address issue and change authorization scope.

1. Collect the exact error and time from the client, then establish whether transport succeeded.
2. For NFS, use the expanded NFS guide’s check-access command and compare numeric file ownership. For SMB, compare the authenticated session identity, share boundary and filesystem ACL.
3. Apply one approved correction and re-run the original operation. Keep a known-denied client/user test to detect accidental access expansion.

05When the scope points to a shared dependency

When all clients fail at once, compare the outage time with LIF/port events, volume state, protocol service changes and DNS/directory availability. When only one folder fails, prioritize its namespace junction and effective security. When file opens slow after antivirus integration but existing transfers are normal, include Vscan/FPolicy service availability in the comparison. These scopes guide the next test; none prove a cause without evidence.