NFS Datastore Mount Errors in VMware ESXi: Troubleshooting and Prevention Guide

NFS datastore mount errors in VMware ESXi can prevent virtual machines from accessing shared storage and may be caused by network connectivity, NFS permissions, firewall rules, DNS, or protocol mismatches. Identifying the root cause requires checking both the ESXi host and NFS server.

This guide explains the most common NFS datastore mount problems and provides practical troubleshooting steps. You’ll learn how to verify VMkernel connectivity, NFS exports, permissions, NFS versions, firewall settings, DNS resolution, and ESXi logs to restore reliable datastore access.

This guide is built to be used two ways: read it top to bottom to understand the full failure landscape, or jump straight to the root cause matching your symptom and work that section in isolation. Each root cause includes diagnosis, fix, risk level, and verification together so you don’t have to cross-reference sections mid-incident.

Root Cause Priority Overview

Ranked by how often each actually shows up in the field, highest-impact first:

Rank	Root Cause	Typical Signature
1	Network connectivity (routing, VLAN, MTU, cabling)	“Unable to connect to NFS server”
2	Configuration errors (/etc/hosts, VMkernel adapter, stale mount state)	Mount fails intermittently or after a host reboot
3	Storage permissions (export ACLs, root squash)	“The mount request was denied by the NFS server”
4	Firewall rules (host-side or physical)	Connects on some hosts, not others
5	NFS service / server-side issues (NFS daemon down, array degraded)	All hosts lose the datastore simultaneously
6	Protocol/version mismatches (NFS 3 vs 4.1, missing VIBs)	Works on some ESXi builds, not others; fails post-patch

Work top-down when you don’t yet know the cause — connectivity issues are both the most common and the fastest to rule in or out.

1. Network Connectivity

Root Cause

The single most common source of NFS mount failures. This covers IP subnet mismatches between the ESXi VMkernel adapter and the NFS server, VLAN tagging not permitted on the physical switch port, MTU/jumbo frame mismatches, and plain physical-layer failures (bad cable, downed switch port, NIC teaming misconfiguration).

Diagnostic Steps

CLI:

# List VMkernel adapters and their IPs/netmasks
esxcfg-vmknic -l

# Confirm the routing table matches the NFS server's subnet
esxcli network ip route ipv4 list

# Test basic reachability to the NFS server from the storage VMkernel interface
vmkping -I vmk1 <NFS_server_IP>

# Test with jumbo frame size if your environment uses MTU 9000
vmkping -I vmk1 -s 8972 -d <NFS_server_IP>

If vmkping fails outright, you have a network-layer problem, not an NFS problem — stop troubleshooting NFS and start troubleshooting the network path.

A very common real-world variant of this: <cite index=”31-1″>the target NFS server’s IP address and the ESXi host’s VMkernel adapter IP address are on different IP subnets, which prevents the host from establishing a connection to NFS storage</cite> — always compare the NFS server’s subnet against your VMkernel adapter’s configured netmask before looking anywhere else.

GUI:

• Host > Configure > Networking > VMkernel adapters — confirm the storage VMkernel port has the correct IP/netmask and is bound to the correct port group.
• Host > Configure > Networking > Physical Adapters > Observed IP Ranges — useful for confirming whether the expected VLAN is actually being observed on the uplink, per <cite index=”34-1″>Host > Configure > Networking > Physical Adapters > Observed IP Ranges</cite>.
• Host > Configure > Networking > Virtual switches — verify the vSwitch/VDS port group’s VLAN ID matches what the physical switch port is trunking.

Logs:

• /var/log/vmkernel.log — look for NFS: 349: Command: (mount) entries and the Vmknic: field, which tells you exactly which VMkernel interface ESXi attempted the mount from.
• If jumbo frames are misconfigured somewhere in the path, you’ll see intermittent, size-dependent failures rather than a hard connection refusal — vmkping with -s 8972 -d isolates this precisely.

Step-by-Step Fix

1. Confirm the NFS server’s IP/subnet against esxcli network ip route ipv4 list output. If they don’t overlap and there’s no route, either re-IP the VMkernel adapter into the correct subnet or add a static route.
2. If VLAN tagging is suspected, engage your physical networking team — this is <cite index=”34-1″>information not available within vCenter, and requires coordination with your physical networking team to confirm the VLAN is explicitly allowed on the relevant switch port</cite>.
3. If vmkping succeeds at default MTU but fails with -s 8972 -d, jumbo frames aren’t consistently configured end-to-end (vSwitch MTU, VMkernel port MTU, and physical switch MTU must all match at 9000). Fix the weakest link, not just the ESXi side.
4. If a specific vmk interface is suspected of being corrupted at the config level, remove and re-add it: <cite index=”29-1″>if pings fail despite correct cabling, remove and reconfigure the storage VMkernel interface (vmk)</cite>.

Version notes: Behavior of vmkping, esxcfg-vmknic, and esxcli network ip route is consistent across 6.x/7.x/8.x. Nothing protocol-specific changes here between versions — this layer is standard IP networking.

Risk Assessment

• Low risk: Read-only diagnostics (vmkping, esxcli network ip route ipv4 list).
• Medium risk: Removing/re-adding a VMkernel adapter briefly interrupts any datastore already using that adapter — schedule a maintenance window if other datastores share the same vmk.

Verification

vmkping -I vmk1 <NFS_server_IP>
esxcli storage nfs list   # Accessible and Mounted columns should both read true

2. NFS Service / Server-Side Issues

Root Cause

The NFS server itself (NAS, filer, or software-defined array) is unreachable, overloaded, degraded, or its NFS daemon has stopped. This is distinguishable from network connectivity issues because all hosts pointed at that server fail simultaneously, while other network traffic to/from the array (management, other protocols) may still work.

Diagnostic Steps

CLI:

esxcli storage nfs list
# Accessible: false / Mounted: true (or false) tells you ESXi still has
# the datastore registered but can't currently reach it — an APD-style state

Logs:

• /var/log/vmkernel.log — repeated NFS: 3500: NFS mount failed... Status: Unable to connect to NFS server with NFS: 2861: Retrying mount request entries confirms ESXi is actively retrying against an unreachable server, matching the documented pattern where <cite index=”35-1″>inconsistent APD (All Paths Down) issues to NFS can also be caused by issues with the host hardware, network, and the NFS storage array itself</cite>, not just the ESXi side.
• Check the array’s own service/system logs directly (outside ESXi) for the NFS daemon (nfsd/mountd) status.

Array-side (vendor-agnostic) checks:

• Confirm the array is listed in the VMware Hardware Compatibility Guide and running a supported firmware/microcode version — <cite index=”35-1″>some array vendors have a minimum microcode/firmware version required to work with the ESXi host</cite>.
• Confirm the array isn’t in a degraded state (failed disk, controller failover in progress, resource exhaustion).

Step-by-Step Fix

1. From the array’s own management interface, confirm the NFS service/daemon is running and the specific export is online.
2. Check array-side capacity and performance — a saturated controller can present as intermittent mount timeouts rather than a hard failure.
3. If array firmware is behind the vendor’s minimum supported version for your ESXi build, plan a firmware update (vendor-specific procedure, outside ESXi scope).
4. Once the array-side issue is resolved, refresh the ESXi-side mount state rather than assuming it will self-heal instantly: <cite index=”29-1″>refresh the NFS mount state to clear transient communication errors</cite>, and if the datastore is missing from the list entirely, re-add it manually with esxcli storage nfs add -H <NFS_IP_OR_HOSTNAME> ....

Version notes: No meaningful difference across 6.x/7.x/8.x — this is entirely array/vendor-side behavior.

Risk Assessment

• Low risk: Verifying array status and logs.
• High risk / requires coordination: Array firmware updates — these typically require their own maintenance window and vendor change-control process, independent of ESXi. Don’t bundle an array firmware update with unrelated ESXi troubleshooting; isolate variables.

Verification

esxcli storage nfs list       # Accessible: true, Mounted: true

Also confirm VM-level I/O has resumed normally (no continued APD/PDL alarms in vCenter under Host > Monitor > Issues and Alarms).

---

3. Configuration Errors (Host / Datastore)

Root Cause

Stale or incorrect host-level configuration — most commonly a bad /etc/hosts entry, a corrupted VMkernel network config, or an inconsistent mount state left behind after a failed operation.

Diagnostic Steps

CLI:

esxcli storage nfs list
cat /etc/hosts

A textbook example: a host loses access to an NFS datastore because <cite index=”32-1″>the ESXi host contains incorrect NFS server information in its /etc/hosts file, and since the host uses that file for hostname resolution, a faulty IP mapping directly prevents the network connection required to reach the storage</cite>. This produces the same esxcli storage nfs list symptom — Accessible and Mounted both showing false — as a straight network-layer failure, so always check /etc/hosts before assuming a deeper network problem.

Logs:

• /var/log/hostd.log — look for Hostsvc.FSVolumeProvider entries with VmkCtl mount or ProcessNas failed.
• /var/log/vmkernel.log — cross-reference timestamps with hostd.log entries for the same mount attempt.

Step-by-Step Fix

1. Never hand-edit /etc/hosts directly — per official guidance, <cite index=”32-1″>do not modify this file directly; use esxcli instead</cite>. First back it up: cp /etc/hosts /etc/hosts.backup
2. Correct the entry using the supported esxcli/host-profile workflow rather than a raw text edit, then save and verify.
3. If the mount state itself looks stale (datastore shows in esxcli storage nfs list but is permanently inaccessible), unmount and re-add cleanly: esxcli storage nfs remove -v <datastore_name>esxcli storage nfs add -H <NFS_server_IP_or_FQDN> -s <share_path> -v <datastore_name>

Version notes: Identical behavior across 6.x/7.x/8.x — /etc/hosts handling via esxcli has been consistent for years.

Risk Assessment

• Medium risk: Removing and re-adding a datastore that’s actively backing running VMs will interrupt I/O to those VMs. Confirm no powered-on VMs are on the datastore first, or plan a maintenance window / storage vMotion the VMs off first if this is a production datastore.
• Always keep the /etc/hosts.backup you took in step 1 until you’ve confirmed the fix works — this is a cheap safety net for a fast rollback.

Verification

esxcli storage nfs list
cat /etc/hosts   # confirm correct FQDN/IP mapping

---

4. Firewall Rules

Root Cause

Required ports blocked either on the ESXi host firewall or on the physical/external firewall between the host and the NFS server. NFS v3 requires the RPC portmapper (TCP/UDP 111) in addition to the NFS data port (TCP 2049); NFS v4.1 needs only TCP 2049, since <cite index=”47-1″>when accessing the NFS server using v4 of the protocol on both client and server, the firewall configuration only requires port 2049 to be open</cite>.

Diagnostic Steps

GUI:

• Host > Configure > Security Profile > Firewall > NFS Client — confirm the ruleset is enabled and check the allowed IP list.

CLI:

esxcli network firewall ruleset list | grep -i nfs
esxcli network firewall ruleset allowedip list -r nfsClient

External/array-side:

• Confirm with your network team that <cite index=”41-1″>ports 111 and 2049 are open on the external network and the NFS server</cite>.

Important Behavioral Quirk

The NFS Client firewall ruleset behaves differently from every other ESXi firewall ruleset — it’s managed automatically by ESXi itself when you mount/unmount datastores, not by you directly in most cases:

• <cite index=”38-1″>Unmounting an NFS v4.1 datastore does not affect firewall state — the first NFS v4.1 mount opens port 2049, and that port remains activated unless you close it explicitly</cite>.
• For NFS v3, the behavior is tied to mount count: <cite index=”38-1″>the nfsClient rule set is deactivated when all NFS v3 datastores are unmounted</cite>, and any manual settings you made to that ruleset get overridden at that point.

Critical ESXi 8.0 U2+ Change

This is a change worth flagging explicitly because it breaks a workflow some teams still assume works: starting in ESXi 8.0 Update 2 (and continuing in 9.0), <cite index=”45-1″>the NFS Client, vSAN encryption, and Trusted Infrastructure key management services can no longer be restricted to specific IP addresses via the ESXi firewall — attempting to uncheck “Allow connections from any IP” for these services fails with the error “Cannot change allowed IP list for this ruleset, it is owned by system service”</cite>. If you’re running 8.0 U2 or later and previously relied on host-level IP restriction for the NFS Client ruleset, that control point is gone. <cite index=”45-1”>If you need to restrict NFS traffic, you must implement those controls at the network layer instead — physical switch ACLs or an external hardware firewall — rather than on the host itself</cite>.

Step-by-Step Fix

1. Confirm ports 111 (NFS v3 only) and 2049 (both versions) are open end-to-end: host firewall, any intermediate firewall, and the NFS server itself.
2. On pre-8.0 U2 hosts, you can adjust the allowed-IP list for the nfsClient ruleset via GUI or esxcli network firewall ruleset allowedip add -r nfsClient -i <IP> if needed.
3. On 8.0 U2+ hosts, do not attempt host-level IP restriction for NFS Client — move that control to your physical/virtual switch ACLs or upstream firewall instead.
4. If using NFS over a routed (Layer 3) connection rather than a flat L2 segment, double check any intermediate firewall/router ACLs specifically — this is a common blind spot since teams often only check the ESXi-side and array-side firewalls.

Version notes:

• 6.x/7.x: NFS Client ruleset IP restrictions are fully configurable at the host level.
• 8.0 U2 and later (including 9.0): IP restriction for NFS Client is locked at the host level by design — push those controls to the network layer.

Risk Assessment

• Low risk: Verifying firewall ruleset state.
• Medium risk: Manually toggling firewall rulesets outside the automatic mount/unmount workflow can produce confusing state — prefer letting ESXi manage the nfsClient ruleset automatically via mount/unmount operations rather than hand-editing it, especially on pre-8.0 U2 hosts.

Verification

esxcli network firewall ruleset list | grep -i nfs
esxcli storage nfs list

Confirm both the ruleset is enabled/active and the datastore shows Accessible: true.

---

5. Storage Permissions

Root Cause

The NFS export’s access control (which client IPs/subnets are permitted, and whether root is squashed to an unprivileged user) doesn’t allow the ESXi host to mount as required.

Diagnostic Steps

Logs:

• /var/log/vmkernel.log — the telltale signature is <cite index=”33-1″>”NFS: 194: NFS mount <NFS_Server_IP>:<share_path> failed: The mount request was denied by the NFS server. Check that the export exists and that the client is permitted”</cite>.

Array-side:

• Review the export’s client ACL — confirm the ESXi host’s VMkernel IP (not its management IP) is in the permitted client list.
• Confirm the root-squash setting. ESXi requires the export to permit root-level access for correct VM operation: <cite index=”41-1″>verify the NFS server permissions are set to no_root_squash</cite>.

Step-by-Step Fix

1. On the array/NFS server, add or correct the export’s client ACL entry to include the exact VMkernel IP or subnet ESXi is mounting from.
2. Set the export option to no_root_squash (terminology and exact setting name vary by NFS server/vendor, but the concept is universal — root on the ESXi host must not be mapped to an unprivileged/anonymous user for VM file operations to succeed).
3. If your environment uses LDAP-backed share permissions and LDAP is unreachable, there’s a documented emergency workaround: <cite index=”41-1″>temporarily set permissions to root/wheel to restore access if LDAP is unreachable</cite> — treat this as a stopgap, not a permanent fix, and revert once LDAP is healthy again.
4. Re-attempt the mount: esxcli storage nfs add --host=<NFS_Server> --share=<NFS_Share_Path> --volume-name=<Datastore_Name>

Version notes: Consistent across 6.x/7.x/8.x — this is entirely array/export-side configuration, not an ESXi version dependency.

Risk Assessment

• Medium risk: Loosening export permissions (especially no_root_squash) has real security implications if the export’s client ACL isn’t also tightly scoped — don’t open root access broadly as a troubleshooting shortcut. Scope the ACL to the specific VMkernel IPs/subnet that need it.
• Low risk: Adding a specific host IP to an existing, correctly-scoped ACL.

Verification

esxcli storage nfs list

Confirm Accessible: true and Mounted: true, then power on a test VM (or verify existing VMs) to confirm actual read/write I/O succeeds, not just that the mount handshake completed.

6. Protocol / Version Mismatches

Root Cause

Mixing NFS versions across hosts sharing the same datastore, mounting over the wrong transport, or missing storage-vendor VIBs after an ESXi patch — all of which produce mount failures that look identical to network issues at first glance but have a completely different fix.

Diagnostic Steps

Logs:

• A mount attempted over UDP instead of TCP produces a distinct signature: <cite index=”35-1″>”WARNING: NFS: 918: Server (IP) does not support Mount Program (100005) Version (3) Protocol (TCP)”</cite> in /var/log/vmkernel.log — this points at a transport-protocol mismatch, not connectivity.
• Post-patch mount failures tied to missing vendor VIBs show the same generic <cite index=”36-1″>”Unable to connect to NFS server: VSI node (5001:)”</cite> signature in both hostd.log and vmkernel.log — don’t assume network/config first if the failure started immediately after a patch cycle.

CLI:

esxcli storage nfs list       # confirm which NFS version each mounted datastore is using
esxcli software vib list | grep -i <storage_vendor>   # confirm vendor VIBs survived the patch

Step-by-Step Fix

1. Never mix NFS versions on the same datastore across hosts. All hosts accessing a given NFS datastore must use the same NFS version (v3 or v4.1) — mixing versions on the same datastore risks data corruption, not just a mount failure.
2. If a UDP/TCP mismatch is found, correct the mount configuration to use TCP explicitly (ESXi’s NFS client requires TCP; this error usually means the server is misconfigured to expect a different transport than what ESXi is presenting).
3. If VIBs went missing after patching (a documented pattern specifically seen with Cisco HyperFlex and other vendor-integrated storage), <cite index=”36-1″>the issue occurs due to missing vendor-specific VIBs on the ESXi host after patching</cite> — reinstall the correct vendor VIB bundle for your installed ESXi build from the vendor’s compatible offline bundle/depot, then reboot and retry the mount.
4. Confirm nconnect support if you’re troubleshooting performance rather than an outright mount failure on NFS v3 — this requires ESXi 8.0 Update 2 or later; NFS v4.1 nconnect requires 8.0 Update 3 or later. Trying to enable this on an earlier build isn’t a bug, it’s unsupported.

Version notes:

• 6.x: NFS v4.1 available but with narrower feature support (no VAAI-NAS at that point in its lifecycle, no SDRS/SIOC/vVols compatibility).
• 7.x: Broad NFS v3/v4.1 support; verify current feature parity against the 7.x Storage guide for your exact update level rather than assuming.
• 8.x: nconnect support added incrementally — v3 in 8.0 U2, v4.1 in 8.0 U3. Also the point where NFS Client firewall IP-restriction was locked down (see Section 4).

Risk Assessment

• High risk / requires downtime: Changing NFS version on an existing production datastore is disruptive — it typically requires unmounting from all hosts and remounting with the new version, meaning VM downtime or a Storage vMotion off the datastore first. Never attempt this on a datastore with running production VMs without a migration plan.
• Medium risk: Reinstalling vendor VIBs requires a host reboot — schedule accordingly and confirm the VIB bundle matches your exact ESXi build first.

Verification

esxcli storage nfs list
esxcli software vib list | grep -i <storage_vendor>

Confirm all hosts in the cluster report the same NFS version for the shared datastore, and confirm Accessible/Mounted are both true on every host, not just the one you were actively troubleshooting.

Risk Assessment and Fix Ordering

When multiple issues are present simultaneously (common after a network change or a patch cycle), work in this order to avoid chasing symptoms:

1. Network connectivity first (Section 1) — nothing else matters if the host can’t reach the server at the IP layer. This is also the lowest-risk category to rule out.
2. Configuration errors (Section 3) — cheap to check, often the actual root cause hiding behind what looks like a network problem (/etc/hosts being the classic example).
3. Firewall rules (Section 4) — check both host-side and physical/external firewall; remember the 8.0 U2+ IP-restriction lockdown if you’re on a recent build.
4. Storage permissions (Section 5) — once you know the host can reach the server, confirm it’s allowed to mount.
5. NFS service/server-side (Section 2) — if everything on the ESXi side checks out, turn attention to the array.
6. Protocol/version mismatches (Section 6) — investigate last, since these are lower-frequency but higher-consequence (data corruption risk, required downtime) — don’t touch NFS version or VIB configuration until you’ve exhausted the lower-risk categories above.

General rule for any fix in this guide: anything that touches a datastore actively backing powered-on VMs should be treated as requiring a maintenance window unless you’ve explicitly confirmed otherwise in that section’s risk assessment. When in doubt, Storage vMotion running VMs off the affected datastore before making changes.

Prevention Best Practices

Optimal NFS Configuration Settings

• Standardize NFS version per datastore, per cluster — document which datastores are v3 vs. v4.1 and enforce it in your build runbooks. Never let a host join a cluster and mount an existing NFS datastore with a different version than the rest of the cluster is using.
• Use dedicated VMkernel adapters and a dedicated/isolated VLAN for NFS traffic — don’t share the storage network with general VM traffic or management traffic. This reduces both performance contention and the blast radius of unrelated network changes.
• Enable jumbo frames (MTU 9000) end-to-end deliberately, not partially — vSwitch, VMkernel port, and physical switch must all agree. A partial jumbo-frame rollout is one of the most common sources of intermittent, hard-to-diagnose NFS issues.
• Use NFS v4.1 with Kerberos where your array supports it, particularly in environments with compliance requirements around authentication — but confirm your array vendor’s current support level for session trunking and nconnect before assuming feature parity with NFS v3.
• Confirm array firmware/microcode meets VMware’s minimum supported version for your target ESXi build before upgrading ESXi, not after — this is a common source of post-patch mount failures.

Pre-Implementation Validation Steps

Before mounting any new NFS datastore in production:

1. Confirm the array is on the current VMware Hardware Compatibility Guide list for your ESXi version.
2. Validate vmkping (including jumbo-frame-sized pings) from every host in the cluster to the NFS server IP — not just one host.
3. Confirm the export’s client ACL includes every VMkernel IP that will need access, scoped as tightly as your environment allows.
4. Confirm no_root_squash (or vendor equivalent) is set correctly on the export.
5. Confirm ports 111 (NFS v3) and 2049 (both versions) are open along the entire path, including any intermediate firewalls — don’t just check the ESXi host and the array; check everything in between.
6. Mount on one host first, verify fully (Section-by-section verification steps above), then roll out to the rest of the cluster — don’t mass-mount across an entire cluster before confirming the first host is stable.

Ongoing Monitoring and Alerting

• Monitor esxcli storage nfs list output (or the equivalent vCenter datastore accessibility state) across all hosts on a schedule, not just when something looks wrong — silent single-host accessibility loss is easy to miss if only one host in a cluster loses a path.
• Alert on vCenter APD (All Paths Down) and PDL (Permanent Device Loss) events specifically for NFS datastores under Host > Monitor > Issues and Alarms.
• Watch /var/log/vmkernel.log for recurring NFS: 2861: Retrying mount request patterns — this indicates an intermittent connectivity issue that hasn’t yet escalated to a full outage, and catching it here is far better than waiting for a hard failure.
• After every ESXi patch cycle, explicitly verify vendor storage VIBs are still present (esxcli software vib list | grep -i <vendor>) before considering the patch cycle complete — don’t assume patching is “done” just because the host booted successfully.
• If you’re on ESXi 8.0 U2 or later, document that NFS Client firewall IP restriction is no longer available at the host level, and confirm your network-layer ACLs (physical switch or external firewall) are actually doing that job — this is easy to lose track of during an upgrade if the host-level control silently stops being enforceable.
• Keep a change log of which NFS version each datastore uses per cluster, and gate any host addition to a cluster on confirming version match before the new host attempts its first mount.

Quick Reference: Log Signatures to Symptom

Log Signature	Location	Points To
Unable to connect to NFS server	hostd.log / vmkernel.log	Network connectivity, firewall, or server down (Sections 1, 2, 4)
NFS: 349: Command: (mount)... Vmknic:	vmkernel.log	Confirms which VMkernel interface attempted the mount — cross-check subnet (Section 1)
The mount request was denied by the NFS server	vmkernel.log	Export permissions / client ACL (Section 5)
does not support Mount Program (100005) Version (3) Protocol (TCP)	vmkernel.log	Transport protocol mismatch (Section 6)
NFS: 2861: Retrying mount request	vmkernel.log	Intermittent/APD-style connectivity issue (Sections 1, 2)
Incorrect /etc/hosts mapping	n/a — check file directly	Hostname resolution misconfiguration (Section 3)
Cannot change allowed IP list for this ruleset, it is owned by system service	vSphere Client error dialog	ESXi 8.0 U2+ firewall behavior change (Section 4) — not a bug
Mount fails only post-patch	hostd.log / vmkernel.log	Missing vendor VIBs (Section 6)

Sources and Currency Notes

This guide draws on current Broadcom Knowledge Base articles and TechDocs for vSphere 6.x through 8.x (several KB articles carry 2025–2026 timestamps, reflecting recent Broadcom KB maintenance rather than newly-discovered issues), plus independent practitioner documentation for esxcli storage nfs command usage. The ESXi 8.0 U2 firewall IP-restriction change for system-owned services (NFS Client, vSAN encryption, Trusted Infrastructure key management) is confirmed current as of this guide’s verification date — if you’re planning an upgrade to 8.0 U2 or later and currently rely on host-level NFS Client IP restriction, treat that as a required pre-upgrade planning item, not something to discover after the fact.

Read more about NFS vs. iSCSI for VMware ESXi