Based on NetApp Knowledge Base: Commvault unable to back up NFS exports on Cloud Volumes ONTAP. Only claims present in the published article are asserted here.
ONTAP 9 Commvault NFS 2026-10-09The symptom NetApp documented
NetApp's Knowledge Base entry "Commvault unable to back up NFS exports on Cloud Volumes ONTAP" applies to ONTAP 9 and Commvault backup software. The published symptoms are specific: the customer can add the cluster to Commvault and see the shares, but backup attempts against NFS exports return errors. The third detail is the one that matters most: packet traces show no NFS connections from Commvault to ONTAP at all.
Why "no NFS connection in the trace" reorders the troubleshooting
When a backup job fails but the array never sees an NFS session, the fault is upstream of ONTAP's NFS server. ONTAP cannot deny a mount it was never asked to serve. That makes the usual suspects, export-policy rules, permissions and root squash, the wrong first stop, even though "can see the shares, cannot back them up" sounds exactly like a permissions problem. Note the split: Commvault can enumerate shares through its cluster integration while an actual data-path mount never reaches the storage. Treating this as an NFS-permissions bug sends you to the wrong layer.
What to check first (editorial checklist)
The description points at the path between the Commvault media agent and the ONTAP LIF. Before touching export policies, confirm that a host-side path exists:
- Reachability and name resolution. Can the media agent resolve and reach the data LIF that owns the export? Prove it with a mount from a plain Linux client on the same subnet as the media agent.
- Which LIF the job targets. A backup target aimed at a management interface, or at a LIF in the wrong SVM, will list shares but never open an NFS session on the data path.
- The export allow-list. Verify the media agent's IP is permitted by the export policy, but treat this as a second check: a blocked client normally still appears in a trace as a refused connection rather than complete silence.
For the NFS-versus-SMB decision and the export-policy model, see our protocol choice reference.
The companion KB that points at the likely culprit
NetApp links a closely related article in the same NAS namespace: "Commvault server unable to communicate with NetApp node via HTTPS". That pairing is a strong signal. Commvault's NetApp integration discovers and drives the cluster over HTTPS and ONTAP APIs; when that control channel is broken or misconfigured, the software can still list shares from partial data while never establishing the NFS data path. Fix the HTTPS/management channel first, then retest the backup. Our BlueXP reference covers the same class of API-surface connectivity that NetApp's own cloud management plane relies on.
What to capture before you open a case
Because the KB resolution is gated behind NetApp support sign-in, arriving with evidence shortens the loop. Capture: a packet trace taken on the media agent during a failed job (to prove whether any NFS traffic left the host), export-policy show and vserver services name-service dns check output on the target SVM, and network interface show -vserver <svm> so you can state which LIF the job should have used. For Cloud Volumes ONTAP deployment models in general, see our Cloud Volumes reference.
Sources: NetApp Knowledge Base: Commvault unable to back up NFS exports on Cloud Volumes ONTAP (last updated Oct 8, 2026). Related: Commvault server unable to communicate with NetApp node via HTTPS.