NFS datastores mount with (1) suffix on vSphere with NetApp storage

Products

• VMware vSAN

Issue/Introduction

Primary Product: VMware vSphere ESXi Component: Storage / NFS

Symptom: An NFS datastore mounts with a "(1)" suffix (e.g., DatastoreName(1)) on specific ESXi hosts within a cluster. This occurs despite the datastore being mounted from the same remote path as other hosts in the cluster. This discrepancy in datastore names/UUIDs prevents cluster-wide operations such as vMotion, High Availability (HA), and Distributed Resource Scheduler (DRS).

Observed Behavior:

• The datastore name is correct on some hosts but appended with (1) on others (typically following a reboot or a new mount attempt).
• The issue is specific to the NFSv4.1 protocol.
• Falling back to NFSv3 resolves the naming inconsistency.

Environment

• Product: VMware ESXi 8.x, VMware ESX 9.x
• Storage: NetApp ONTAP Storage Array
• Protocol: NFSv4.1

Cause

The issue is caused by the backend NetApp storage array generating and presenting asymmetric file handles for the same NFS export to different ESXi hosts.

In NFSv4.1, the ESXi host uses the file handle provided by the storage array to generate a Universally Unique Identifier (UUID) for the datastore. When the storage array provides a different file handle for the same export path to different hosts, ESXi interprets these as distinct storage volumes. To avoid a naming collision in vCenter for what it perceives as two different volumes sharing the same name, the hypervisor appends the "(1)" suffix to the duplicate mount.

Resolution

The root cause resides at the storage layer; therefore, the primary resolution requires vendor engagement.

1. Engage NetApp Support: Request an investigation into the ONTAP operating system to determine why asymmetric or inconsistent file handles are being generated for the same export path when using NFSv4.1.
2. Collect Evidence: Provide NetApp support with packet captures or esxcli outputs showing the differing file handles provided to different hosts for the same mount point.

Workaround

If immediate storage consistency is required to restore cluster features (vMotion/HA), use one of the following methods:

Method 1: Protocol Fallback (NFSv3)

NFSv3 handles metadata differently and typically bypasses the asymmetric handle generation issue observed in the NFSv4.1 stack.

1. Unmount the affected NFS datastore from all ESXi hosts.
2. Remount the datastore using the NFSv3 protocol.
   • CLI Syntax:
     
     esxcli storage nfs add -H <NFS_IP_OR_FQDN> -s /<EXPORT_PATH> -v <DATASTORE_NAME>
     
      

Method 2: Clean Mount Persistence

1. Unmount the datastore from all hosts in the cluster.
2. Perform a rolling reboot of all ESXi hosts to clear stale NFS mount metadata from the hypervisor's memory.
3. Once all hosts are back online, mount the datastore to all hosts simultaneously.