Answer in the order: scope and user impact, evidence, isolation, controlled fix, validation and prevention. Commands are read-only unless the case explicitly calls for a planned change.
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. NFS mount says permission denied after a new export rule. What next?
- Establish the exact client source IP, mount command, version, security flavor, SVM LIF and junction. A rule may match a different subnet or protocol, or a parent junction may block traversal. Do not add a catch-all export rule to make the alert disappear.
- Check the effective volume export policy and ordered rules; test policy matching for the client using the release-appropriate NetApp access-check command, then inspect root and parent namespace access. Once corrected, remount from the same client and test read/write as a non-root UID.
volume show -vserver svm_prod -fields junction-path,policy
vserver export-policy rule show -vserver svm_prod
network interface show -vserver svm_prodThe intended client and security flavor match the least-privilege rule; other clients remain denied.
2. One SMB user can browse a share but cannot save. How do you isolate it?
- Ask for exact UNC path, user identity, workstation, operation and timestamp. Compare with a working user on the same path and a working path for the affected user. Successful browsing suggests the SMB session and some traverse permissions work; failure to create may be share ACL, directory ACL, quota, read-only volume or application behavior.
- Inspect the authenticated identity and group membership, share permission, file-system effective permission and any explicit deny. Check volume capacity and quota only if the error or behavior indicates it. Fix the narrow ACL or group issue and re-test file create and delete with an authorized test account.
A named test user can perform exactly the required operation without opening access for unrelated accounts.
3. Users report SMB files take 15 seconds to open after an AV rollout.
- Compare latency before and after the rollout and test files inside and outside the Vscan policy scope. Check Vscan connected scanners, engine logs, scan queues, scanner CPU and network latency. Confirm a file-size or extension policy is not sending large VM or database files through a slow scan path.
- If all scanners disconnect and scanning is mandatory, access behavior can become denial rather than only latency. Escalate the security decision and follow the agreed outage runbook. Add capacity or tune approved exclusions with application and security owners; measure again rather than turning off scanning for everyone.
vserver vscan connection-status show
vserver vscan on-access-policy show -vserver svm_prodMeasured file-open latency improves while the approved scanning scope remains effective.
4. FPolicy is enabled but vendor sees no events. What could be wrong?
- Check a test operation that actually matches the configured protocol, event and scope. A policy can be on while the test volume is excluded, the operation is not subscribed, or the external engine has no connected server. Compare policy, event, engine, scope and server logs at a common timestamp.
- Validate routing, server port, TLS/certificate settings and vendor service. Send an operation on an included volume and a control operation outside scope. Only broaden the event list after confirming the narrow configuration works.
vserver fpolicy show -vserver svm_prod
vserver fpolicy show-engine -vserver svm_prod
vserver fpolicy policy scope show -vserver svm_prodOne expected event reaches the vendor and one out-of-scope event does not.
5. A NAS volume reaches 100% full while snapshots exist. What do you do?
- Separate logical volume usage, snapshot usage, aggregate physical headroom, thin provisioning and autosize behavior. Identify the application error and whether the volume or containing aggregate is full. Do not delete recovery points without checking retention and SnapMirror dependencies.
- If approved and the aggregate has headroom, expand the volume or use a documented temporary capacity measure, then verify client writes resume. Establish growth cause, snapshot retention and thresholds; protect the current recovery objective while remediating.
volume show-space -vserver svm_prod
volume snapshot show -vserver svm_prod
storage aggregate showUsers can write again and aggregate headroom and replication remain healthy.
6. After DR failover, the SMB share is up but applications fail.
- Confirm that the destination copy is writable and that the expected shares, data LIFs, DNS records, AD computer account and routing are valid at the DR site. Then check application dependencies: database/log volumes, service account permissions, Kerberos time, and client cache of the old name/address.
- Run one application transaction from a DR client and compare with an ordinary SMB file test. If file I/O works but the app fails, investigate its own dependencies rather than repeatedly breaking/resyncing SnapMirror. Prevent simultaneous writes to the original primary during DR operation.
One authoritative writable copy serves a complete application transaction, with accepted data-loss window recorded.