Troubleshooting VMware ESXi NFS Datastore Mount Failures

An NFS datastore that refuses to mount on VMware ESXi often produces an unhelpful timeout rather than a clear storage error. The NAS may be online, the export may be visible from another server, and existing virtual machines may continue running while a new host cannot connect.

Timeouts usually indicate that traffic is being dropped, routed through the wrong VMkernel interface, or delayed by an NFS, DNS, firewall, or MTU mismatch. A structured check separates a VMware configuration problem from an issue on the NAS or network.

This matters in Australian environments where hosts may be spread between Sydney, Melbourne, Brisbane, Perth, or a regional site. WAN latency, carrier-managed firewalls, data residency requirements, and hybrid infrastructure can make an NFS mount appear unreliable even when local testing looks healthy.

Confirm The Exact Mount Failure

Start in vCenter or the ESXi Host Client and record the full error, including the datastore name, NAS address, and whether the operation timed out during discovery or mounting. A stale datastore entry can create confusion, particularly after a NAS migration or IP address change.

Check the host logs immediately after reproducing the failure:

grep -i nfs /var/log/vmkernel.log
grep -i nfs /var/log/hostd.log
grep -i timeout /var/log/vobd.log

Look for messages involving connection timeouts, unreachable exports, RPC failures, or an unexpected NFS version. Compare the failing ESXi host with one that already has the datastore mounted. Differences in VMkernel networking, DNS resolution, and ESXi build level often reveal the cause quickly.

Validate The NFS Export And Version

On the NAS, confirm that the export path is exactly the same as the path entered in ESXi. An export such as /volumes/vmware is different from /volumes/vmware/, and some platforms expose a junction or namespace that is not valid for every NFS client.

Review the export policy or host access list. The ESXi management IP is not always the source address used for NFS traffic; it may be the IP assigned to a dedicated storage VMkernel adapter. Permit the correct host or subnet, and verify read/write access where required.

NFS version compatibility also matters. NFSv3 commonly depends on port 2049 plus RPC services, while NFS 4.1 uses a different session model and may require correct datastore and server support. Do not assume that an export working with NFSv3 will work unchanged with NFS 4.1. Select the intended version explicitly and check the NAS documentation.

Check VMkernel Routing And Reachability

In ESXi, the storage path must use a VMkernel adapter with suitable connectivity. Confirm that the intended vmk interface has the correct IP address, VLAN, subnet, and physical uplinks. If NFS traffic crosses a routed boundary, check the ESXi routing table and the return route on the storage network.

Useful tests include:

esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list
vmkping -I vmk2 10.20.30.15

Replace vmk2 and the address with the storage VMkernel and NAS IP. A failed ping does not prove that NFS is unavailable, but it strongly indicates a network or VLAN issue. Test the NAS IP rather than its hostname first, then test name resolution separately. In a Perth-to-Sydney hybrid design, a route, firewall, or latency problem can be expected to affect mounting even if both sites have functioning local networks.

Test Ports, Firewalls And MTU

A firewall may allow ICMP while dropping NFS or RPC traffic. Check the host firewall, distributed firewall rules, physical firewalls, and any ACLs on the storage VLAN. NFSv3 environments may require more than TCP/UDP 2049, depending on how mount and RPC services are configured. NFS 4.1 generally simplifies the port requirement, but it still needs reliable access to the server endpoint.

Use packet captures when basic tests do not explain the timeout. On the NAS, inspect whether requests arrive and whether responses leave. On ESXi, identify repeated SYN packets, unanswered RPC requests, or TCP resets. A silent drop usually points to filtering or routing; an immediate reset is more likely to indicate a service or policy rejection.

Jumbo frames must be configured consistently across ESXi, switches, and the NAS. Test the effective MTU with a non-fragmenting ping:

vmkping -I vmk2 -d -s 8972 10.20.30.15

Adjust the payload for the configured MTU. If standard-size pings work but jumbo tests fail, either correct the entire path or temporarily use standard frames while troubleshooting.

Check	Expected result	Likely fault if it fails
NAS IP ping from storage VMkernel	Replies with stable latency	VLAN, route, uplink, or ACL
DNS lookup from ESXi	Correct forward and reverse records	DNS or stale hostname
TCP access to NFS endpoint	Connection permitted	Firewall or NAS service
Export policy review	ESXi storage IP is authorised	NAS access control
MTU test	Payload passes without fragmentation	Jumbo-frame mismatch
NFS version test	Selected version is supported	Protocol or NAS compatibility

Review DNS, Time And Identity Settings

Although NFS mount timeouts are usually network-related, incorrect DNS can send ESXi to an old NAS address or an unreachable interface. Check forward and reverse records, short-name resolution, and any split-horizon DNS used between production and disaster recovery sites.

Time synchronisation is especially important for NFS 4.1 environments using identity or security features. Verify that ESXi and the NAS use reliable NTP sources and sensible time zones. Australian organisations commonly operate across AEST, ACST, and AWST, so a poorly maintained regional NTP design can create confusing log timestamps and authentication symptoms.

Avoid relying on a hostname until IP-based testing succeeds. Once connectivity is proven, use the fully qualified NAS name where the storage platform and VMware design require stable name resolution.

Recreate The Datastore Carefully

If the export, network, and protocol checks pass, remove stale configuration only after confirming that no virtual machines depend on the datastore. Record the existing mount path and NFS version first. A forced removal can cause unnecessary disruption or leave a misleading inventory state.

For a new NFSv3 mount, a typical ESXi command is:

esxcli storage nfs add \
  -H nas01.example.com \
  -s /volumes/vmware \
  -v VMFS-NFS01

For NFS 4.1, use the corresponding esxcli storage nfs41 command supported by the ESXi release. Prefer the Host Client or vCenter for normal administration, and use the CLI to validate syntax and isolate host-specific behaviour. After mounting, check datastore accessibility, multipathing or session status where applicable, and recent vmkernel.log entries.

Prevent Recurring NFS Mount Problems

Document the storage VMkernel VLAN, IP ranges, MTU, routing, NAS export policy, NFS version, and firewall ports. This is valuable during after-hours incidents, especially when storage is managed by a separate team or a carrier in an Australian colocation facility.

Useful operational safeguards include:

• Keep ESXi, NAS firmware, and switch software within supported compatibility matrices.
• Monitor NFS latency, retransmissions, packet loss, and datastore accessibility.
• Use separate, documented storage paths where the design supports them.
• Test failover from every ESXi host before a maintenance window.

A small runbook should also capture the commands used for reachability, the correct export path, and the approved change process. In the Australian market, where organisations often combine local NAS, hosted VMware, and public cloud recovery, documenting which traffic stays on-site and which crosses a WAN prevents many false diagnoses.

When a mount fails again, compare the working and failing hosts rather than repeatedly retrying the operation. That comparison usually identifies whether the problem belongs to ESXi networking, the NFS service, or the path between them.