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

NAS interview questions and detailed answers

NFS, SMB, SVMs, permissions, multiprotocol access, protection and operations.

Scenario

Use these answers to explain both the concept and what you would inspect in ONTAP. Replace the example SVM and volume names with your experience; discuss the actual protocol versions and security choices you have operated.

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. What is an SVM and why do NAS clients use data LIFs?

  1. An SVM is an administrative and protocol boundary. It owns NAS namespace, volumes, NFS/SMB services, name services and data LIFs. A client resolves an SVM service name or connects directly to a data LIF; it does not use a cluster-management address for normal file I/O.
  2. In an interview, give a concrete design: svm_prod has two NAS data LIFs across nodes, a DNS name used by clients, an NFS server and an SMB server as required. Explain that network redundancy requires correct broadcast-domain/failover design and switch/VLAN configuration, not simply two IP addresses.
Read-only discussion aids 
vserver show
network interface show -vserver svm_prod
network port show
Verify

Explain which object owns the protocol and which interface carries client traffic.

2. How do an NFS export policy, rule and junction path work together?

  1. A NAS volume is mounted into the SVM namespace at a junction path. The client mounts the exported namespace through a data LIF. The export policy associated with a volume or qtree contains ordered rules matching client, protocol and security flavor, plus separate read-only, read-write and superuser treatment. Parent namespace traversal also matters.
  2. Example: Linux client 192.0.2.45 mounts 192.0.2.30:/projects using NFSv4.1. If the mount is denied, check that /projects is mounted, the rule matches the actual client IP and NFS version/security flavor, the parent SVM root can be traversed, and UNIX ownership or ACL grants the requested operation.
Read-only example checks 
volume show -vserver svm_prod -fields junction-path,policy
vserver export-policy rule show -vserver svm_prod
vserver nfs show -vserver svm_prod
Verify

State why a rule allowing mount can still leave write operations denied.

3. Compare NFSv3 and NFSv4 in day-to-day administration.

  1. NFSv3 uses separate protocol services for functions such as mount and locking and typically relies on numeric UID/GID authorization with AUTH_SYS unless a stronger security design is configured. NFSv4 has a single namespace model, integrated locking and distinct identity/domain considerations; minor versions and Kerberos support depend on clients and ONTAP settings.
  2. Interview answer: start with the client and SVM versions actually enabled, test the mount with an explicit version, verify UID/GID or NFSv4 identity mapping, and review firewall and Kerberos settings if relevant. Do not assume changing mount version fixes file ownership or export rule errors.
Verify

Name one client-side test and one ONTAP-side check for a version-specific mount failure.

4. Why might an SMB user see access denied even with share access?

  1. Effective access depends on SMB authentication, share permissions and file-system permissions. The share can allow an AD group while an NTFS ACL on a directory denies a write, or a mixed-security object may involve UNIX identity mapping. DNS and AD time/trust must also work for sign-in.
  2. Example: a member of EXAMPLE\ProjectReaders opens \svm-files\projects but cannot create a file. Confirm the authenticated identity, group token, share ACL and file/directory ACL for the exact path. Compare a permitted user and denied user; changing the share to Everyone risks masking the real ACL fault.
Read-only checks · adapt identity and path 
vserver cifs show -vserver svm_prod
vserver cifs share show -vserver svm_prod
vserver security file-directory show-effective-permissions -vserver svm_prod -win-user-name EXAMPLE\testuser -path /projects -share-name projects
Verify

Separate authentication from authorization and explain the two permission layers.

5. How do you design safe multiprotocol access?

  1. Choose the volume security style based on the primary workload, then document how Windows and UNIX identities map. In mixed-security volumes, the effective style of individual objects can vary; an NTFS ACL and UNIX mode bits do not simply combine into a universal permission mask.
  2. Example: an SMB service account writes a file that an NFS application must read. Inspect the effective file security style, Windows-to-UNIX name mapping, group membership and both clients’ view of ownership. Test create, read, rename and delete before opening a production mixed-protocol share.
Verify

Describe the actual identity translation rather than saying NFS and SMB permissions automatically match.

6. What do Snapshot and SnapMirror each protect?

  1. A Snapshot provides a point-in-time recovery point on a volume. It is useful for quick local file or volume recovery but shares the source cluster failure domain. SnapMirror transfers recovery points to another destination for DR or retention according to relationship policy and schedule.
  2. Give an RPO/RTO example: hourly asynchronous replication can lose writes since the last completed transfer; application restart, DNS changes and consistency also affect RTO. A healthy relationship alone does not prove a tested restore or that observed lag meets the promised RPO.
Read-only discussion aids 
volume snapshot show -vserver svm_prod
snapmirror show -fields health,lag-time,last-transfer-error
Verify

Explain why an on-cluster Snapshot does not replace an off-cluster recovery copy.

7. How would you troubleshoot slow NAS access?

  1. Define whether slow means name resolution, session establishment, metadata browsing, file open or sustained throughput. Compare one client against many, one share against others, and time windows against a known baseline. Check client network, DNS/AD/LDAP, data LIF placement and physical port errors.
  2. Then correlate volume/aggregate latency, disk or node load, QoS, protocol latency, and Vscan/FPolicy external server delay if present. Measure each layer before moving a LIF or relaxing a security policy. In an answer, show the evidence that would falsify each hypothesis.
Initial ONTAP checks 
system health alert show
network interface show
network port show
volume show-space
Verify

State a measurable symptom, comparison group, probable layer and next targeted test.

NetApp references