Storage Admin HubConfiguration · Protection · Recovery
All guides/Interview Q&A
Interview Q&A · ONTAP 9

NetApp interview: advanced troubleshooting

Ten deeper cases on DR lag, multipath, identity, security, ransomware and performance.

Scenario

At this level, interviewers look for a hypothesis, evidence that can disprove it, an impact-aware change and a measurable recovery. Explain why a plausible shortcut could make the incident worse.

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. SnapMirror shows healthy, yet the application RPO is missed. Why?

  1. Relationship health says the relationship is operating, not that the last good recovery point is young enough. Compare last-transfer end timestamp and lag against the committed RPO. Inspect schedule, transfer duration, bandwidth throttles, source change rate, queued jobs and intercluster path errors. Multiple application volumes may need coordinated consistency.
  2. Example: an hourly schedule starts on time but a transfer runs for 90 minutes, so each completed point trails the live app by more than an hour. Increase transfer frequency only after measuring bandwidth/capacity, reduce churn or redesign the recovery objective. Validate by recording several consecutive actual transfer ages.
Read-only checks 
snapmirror show -fields health,lag-time,last-transfer-end-timestamp,last-transfer-error
Verify

Use observed recovery-point age, not schedule text, to prove RPO.

2. After a SAN volume move, latency rises while all paths remain visible.

  1. SLM and ALUA can leave hosts using non-optimized paths if reporting nodes were not prepared or the host did not update path states after the move. Check volume owner, LUN reporting nodes, FC/iSCSI target paths, host multipath states and switch congestion before blaming the aggregate.
  2. If the move crossed HA pairs, follow NetApp’s sequence to add destination reporting nodes before the move and remove unnecessary old paths after host path updates. Make corrections during an approved window and compare the same workload’s latency before and after.
Read-only checks 
volume show -fields node,aggregate
lun mapping show -fields reporting-nodes
network interface show
Verify

The host has expected optimized paths and latency returns to baseline.

3. Why would NFS root work on one export and map to nobody on another?

  1. Export rules specify superuser treatment separately from read/write access. AUTH_SYS root may be mapped to an anonymous UID for one policy while another deliberately permits superuser. Parent namespace policies and NFSv4 identity settings can also change results.
  2. Compare the exact matching rule index, client source IP, protocol, security flavor, superuser field and anonymous user. Do not grant root to an entire subnet because a test file failed; fix the narrow export or application UID requirement.
Read-only checks 
vserver export-policy rule show -vserver svm_prod
volume show -fields policy,junction-path
Verify

Explain the effective root mapping and the least-privilege correction.

4. SMB clients intermittently get access denied after an AD change.

  1. Separate failed authentication from file authorization. Check DNS SRV records, domain controller reachability, time skew, trusts, account/group changes, Kerberos ticket freshness and name mapping. Collect a single timestamped client and SVM error; compare with an unaffected client to narrow the DC or token path.
  2. If the SMB session succeeds but one folder fails, inspect share and object ACL and group token. If sessions fail cluster-wide, investigate AD/DNS and SVM service before editing file ACLs. Restore service with the minimum approved identity or DNS change, then validate across clients.
Read-only checks 
vserver cifs show -vserver svm_prod
vserver services name-service dns show -vserver svm_prod
network interface show -vserver svm_prod
Verify

One consistent identity and permission path works across representative clients.

5. What changes when Vscan or FPolicy external servers fail?

  1. Vscan on-access scan-mandatory behavior determines whether eligible SMB operations can proceed without a connected scanner. FPolicy mandatory synchronous screening can deny matching operations when all external servers are unavailable or time out. The exact client symptom depends on policy and monitored operation.
  2. Check connection status, event scope, server service, network and timeout logs before changing an unrelated export/share. A temporary fail-open decision reduces protection, so have the security owner approve it and document affected time and data. Add redundant servers and monitor queues to reduce recurrence.
Read-only checks 
vserver vscan connection-status show
vserver vscan on-access-policy show
vserver fpolicy show
vserver fpolicy show-engine
Verify

State the configured failure behavior and the measured client impact.

6. A volume is full, but deleting a Snapshot does not free expected space.

  1. A retained block can be referenced by several snapshots, a clone or the active file system. Removing one snapshot frees only blocks no longer referenced elsewhere. The containing aggregate may also be constrained by other volumes or metadata.
  2. Check active and snapshot space, clone dependencies and aggregate physical usage. Identify which recovery points are mandated by SnapMirror or retention; do not delete them merely because the logical volume is at 100%. Add capacity, adjust autosize within headroom or remove approved obsolete data, then verify reclaimed physical space.
Read-only checks 
volume show-space
volume snapshot show
storage aggregate show
snapmirror show
Verify

Explain the block references and observe real physical headroom after remediation.

7. How do you triage a ransomware alert on an ONTAP NAS volume?

  1. Preserve evidence and scope the alert: affected volume, client/user, time, unusual extensions or write burst, available snapshots and other impacted volumes. Coordinate with security to isolate the malicious client account or host. Avoid deleting suspect recovery points or immediately clearing the alert.
  2. Check ONTAP ARP status and snapshot availability for the release in use, protected destination copies, Vscan/FPolicy logs and backup integrity. Restore representative data to an isolated location, validate application consistency and use a controlled production recovery plan. Multi-admin verification and snapshot locking can make destructive changes harder, but feature support and policies vary by release.
Verify

Contain the writer, preserve trustworthy recovery points and demonstrate a tested restore.

8. When is a SAN path failure an application incident?

  1. A multipathed host may continue serving I/O after one path fails, but redundancy is lost and latency may rise if only non-optimized paths remain. Assess path count and state against the supported host design, not just whether the application is still alive.
  2. Compare both fabrics, host HBA/NIC logs, target LIF, switch errors, zoning/session and SLM reporting nodes. Fix one failing component at a time; retest under approved load and open a ticket before the remaining path fails.
Verify

Service is healthy and the originally designed path redundancy is restored.

9. How do you distinguish storage latency from host or network latency?

  1. Pick a specific affected operation and time window. Measure application response, host queue and retransmits, network or fabric errors, ONTAP protocol and volume latency, node CPU and aggregate disk load. Compare an unaffected client or volume on the same infrastructure to isolate the layer.
  2. For NAS file opens, include DNS/AD, Vscan and FPolicy server delay. For SAN, include optimized versus non-optimized ALUA paths and host queue depth. State a hypothesis and a measurement that could disprove it before changing QoS or moving a volume.
Verify

The same workload improves after fixing the measured bottleneck, with other workloads unaffected.

10. What makes a rollback plan for a data migration safe?

  1. Before target writes, a failed cutover may allow clients to return to the original source, assuming it was not altered. After target writes start, the original source is stale. Rolling DNS back without synchronizing those new writes can silently lose data.
  2. Define one authoritative writable copy, freeze and log client writes at each transition, retain both copies, and plan an approved reverse replication or reconciliation method. Test identities and application transactions at the recovered site before reopening production.
Verify

The plan identifies the point after which simple DNS rollback is no longer valid.

NetApp references