VMware ESXi and vSphere Cluster Management

NFS Access Controls for VMware ESXi Datastores

Learn how VMkernel networking, NFS export permissions, client authorization, read-write access, and root_squash settings affect VMware ESXi NFS datastores.

An ESXi NFS datastore depends on two control layers working together: network connectivity from the ESXi host to the NAS, and permissions enforced by the NAS through its NFS export policy. A successful datastore configuration requires both.

NFS, or Network File System, is the protocol ESXi uses to access files stored on a remote NAS. An NFS datastore is the VMware datastore created from an NFS export. The ESXi host mounts that export and performs file operations for virtual machines.

How NFS access controls work in vSphere

The NAS controls which client addresses may mount an export and whether those clients can read, write, create, rename, lock, and delete files. vSphere can request that ESXi mount an export, but datastore creation cannot override a NAS rule that denies the host or makes the export read-only.

For a shared datastore, every ESXi host that may run virtual machines from that datastore must be able to reach and use the same export. If one host is missing from the NAS allowlist, has a different source IP, or receives different permissions, that host may fail to mount the datastore or may be unable to access virtual machine files.

Prerequisites for an ESXi NFS datastore

Prepare the complete access path before using the vSphere datastore workflow. The dependency chain is:

Create or select a VMkernel adapter for NFS storage traffic.
Provide IP addressing, VLAN connectivity, routing, and firewall access between the VMkernel interface and the NAS.
Create a filesystem or storage volume on the NAS.
Publish the exact filesystem path as an NFS export.
Authorize the intended ESXi host addresses or a tightly controlled storage subnet.
Set the export to read-write for every host that needs to use it.
Permit the root access behavior required by ESXi, normally by disabling root squashing for this dedicated export.
Add the export as an NFS datastore on each intended ESXi host.

Requirement	Where It Is Configured	Why It Matters	Validation Method
VMkernel interface	ESXi networking	Provides the host-side interface for storage traffic.	Inspect the adapter, IP address, enabled services, and source address used for storage.
Storage network reachability	Switches, VLANs, routing, and firewalls	Allows TCP traffic between ESXi and the NAS.	Run an ESXi VMkernel-to-NAS reachability test and review network policy.
NAS filesystem	NAS storage configuration	Provides the storage location behind the export.	Confirm that the filesystem or volume exists, is healthy, and has capacity.
NFS export path	NAS export configuration	Identifies the filesystem path that ESXi will mount.	Compare the published path character-for-character with the path entered in vSphere.
NFSv3 over TCP	NAS protocol settings and ESXi datastore workflow	Ensures that both sides use a compatible protocol and transport.	Confirm NFSv3 availability and TCP transport on the NAS and the selected version in ESXi.
Authorized ESXi clients	NAS export policy	Prevents unauthorized systems from mounting the export.	Check each ESXi storage source IP against the export allowlist.
Read-write access	NAS export policy and filesystem permissions	Allows ESXi to manage datastore files.	Verify export mode and test file creation, modification, and deletion.
Root access / no_root_squash	NAS export policy	Preserves the privileged identity ESXi requires for datastore operations.	Inspect the effective root-mapping rule and test virtual machine file operations.

NFS protocol and transport requirements

For an NFSv3 datastore configuration, use NFS version 3 over TCP. NFS version and transport are compatibility choices: the protocol selected by ESXi must be supported by the NAS export, and the NAS must allow the required TCP traffic.

Do not treat NFSv3 and NFSv4.1 as interchangeable permission models. NFSv4.1 can involve different session behavior, identity handling, namespace design, and vendor-specific configuration. Follow the VMware and NAS compatibility guidance for NFSv4.1 if that version is selected. The root-squash discussion here applies to an NFSv3 ESXi datastore export and should not be used to assume that every NFSv4.1 deployment has identical settings.

Authorizing ESXi clients

Client authorization is the export rule that defines which hosts or networks may mount and use a filesystem. Prefer explicit ESXi host IP addresses when the environment is small. A tightly scoped storage subnet or controlled host group can be appropriate when supported by the NAS, provided it contains only intended storage clients.

Use the exact export path that the NAS publishes. A NAS can contain several similar paths, nested exports, or aliases. Entering a parent path, a child path, or a spelling variant may select a different export rule or produce a mount failure.

Every ESXi host expected to use the datastore must have read-write authorization. Inconsistent rules can produce a partially functioning cluster: some hosts mount the datastore while another cannot see it, or one host can mount it but cannot perform the same file operations.

Root identity and root_squash

On Unix-like systems, root is the privileged account conventionally identified by UID 0. When an NFS client sends a request as root, the NFS server may apply root_squash. This maps the request to an unprivileged anonymous UID/GID rather than honoring UID 0.

Root squashing limits the damage that could result if a privileged account on an authorized client were compromised. A client that appears to be root cannot automatically exercise root privileges on the exported filesystem.

ESXi requires root-level access to manage virtual machine files on an NFS datastore. Depending on the operation, ESXi must create, modify, rename, lock, and delete files and directories. If the NAS maps ESXi root requests to an anonymous identity whose filesystem permissions are insufficient, the datastore may fail to mount or virtual machine file operations may return permission errors.

Why no_root_squash is used for an ESXi datastore export

no_root_squash preserves the root identity supplied by an authorized NFS client. For the NFSv3 ESXi datastore scenario, the export must permit the ESXi hosts to retain the required root access rather than mapping them to an anonymous identity.

Export Option	Treatment of Client Root	Security Effect	Effect on ESXi NFS Datastore Access
root_squash	Maps client root requests to an anonymous, unprivileged UID/GID.	Reduces the impact of a compromised privileged client.	Can prevent ESXi from completing required datastore and virtual machine file operations.
no_root_squash	Retains the root identity for an authorized client.	Allows that client root account to act with root privileges on the export; broad exposure is dangerous.	Provides the root-level access required by the ESXi NFS datastore export scenario.

Do not enable no_root_squash for broad networks or untrusted clients. Limit it to explicit ESXi host addresses or a dedicated, protected storage network. The security assumption is that an authorized ESXi host and its storage path are trusted. If another system can use the same export, root on that system may be able to alter or delete datastore files.

Vendor-neutral export policy example

NAS syntax differs by platform. The following is pseudoconfiguration, not a command to paste into a particular NAS:

export path: /storage/vmware-ds01
allowed clients: 192.0.2.21, 192.0.2.22
protocol: NFSv3
transport: TCP
access: read-write
root mapping: no_root_squash
filesystem: healthy and writable

If a NAS uses a different label, look for an equivalent setting such as root access, privileged port access, or an export identity-mapping option. Confirm the effective policy in the NAS administration interface rather than relying only on the name of a checkbox.

End-to-end datastore setup workflow

Design the storage path. Where practical, place NFS traffic on a dedicated storage VLAN or another isolated network path.
Configure VMkernel networking. Create or select a VMkernel adapter that can reach the NAS, and confirm its IP address, VLAN, gateway, and relevant storage service settings.
Prepare the NAS filesystem. Create a dedicated filesystem or volume with sufficient capacity and verify that it is healthy and writable.
Publish the export. Export the exact filesystem path using NFSv3 over TCP, read-write access, and a client rule limited to the intended ESXi hosts.
Set root handling. Use no_root_squash, or the NAS vendor's equivalent root-preserving option, only for the explicitly authorized ESXi clients.
Add the datastore. In the vSphere workflow, enter the NAS address and exact export path, select the compatible NFS version, and complete the mount operation.
Repeat for the cluster. Mount the same export on every ESXi host that must run virtual machines from the datastore.
Validate operations. Confirm that the datastore is writable and that ESXi can create, modify, access, lock, and remove test virtual machine files as appropriate for the environment.

vSphere datastore configuration and NAS export policy are complementary controls. A correct vSphere entry cannot compensate for a missing client allowlist entry, an incorrect export path, read-only access, a blocked firewall, or root squashing that prevents required operations.

Verification and operational checks

Test reachability from the storage VMkernel interface to the NAS address before attempting the mount.
Confirm that VLAN tagging, routing, and firewall rules permit the required NFSv3 TCP traffic.
Verify that the NAS exposes the selected NFS version and transport.
Inspect the exact export path and compare it with the path entered during datastore creation.
Check the effective client allowlist using the source IP address that ESXi actually uses.
Confirm read-write export status, filesystem permissions, quotas, capacity, and filesystem health.
Verify the root-squash or root-preserving setting for each authorized ESXi client.
Inspect ESXi datastore and NFS mount status after the mount attempt.
Review ESXi host logs and NAS access logs for denied mounts, rejected source addresses, protocol mismatches, or permission failures.

Common NFS datastore access failures

Symptom	Likely Cause	NAS-Side Check	ESXi-Side Check	Corrective Action
Datastore cannot be mounted	No VMkernel path, wrong address or path, blocked traffic, missing client authorization, or NFS version mismatch.	Confirm export path, protocol, transport, allowlist, and NAS logs.	Check VMkernel IP, VLAN, routing, firewall reachability, and datastore inputs.	Correct the network or export settings, then retry with the exact published path.
Host cannot see the export	The host source IP is not authorized or uses a different storage network.	Add the correct host address or tightly scoped subnet and confirm the rule is active.	Identify the VMkernel interface and source address used for NFS.	Make client authorization and storage networking consistent across hosts.
Permission denied when accessing VM files	root_squash, insufficient anonymous permissions, conflicting filesystem ACLs, or a read-only export.	Inspect root mapping, filesystem ownership, ACLs, and export mode.	Review datastore and host logs for file-operation failures.	Provide read-write access and required root access only to the authorized ESXi clients.
Only some cluster hosts can use the datastore	One or more hosts are missing from the export rule or have different network paths.	Compare effective export rules for every host IP.	Compare VMkernel adapters, VLANs, routes, and firewalls.	Add missing hosts and standardize the storage path and permissions.
Datastore is mounted but is not writable	Read-only export, quota or capacity issue, filesystem error, or root identity mapping.	Check export mode, capacity, quotas, filesystem health, and root handling.	Test datastore file operations and inspect mount status.	Restore read-write operation, resolve capacity or filesystem problems, and correct identity mapping.

Security boundaries and least privilege

Use a dedicated storage VLAN or isolated network path for NFS where practical.
Restrict the export to the ESXi hosts that require access.
Prefer explicit host addresses or a tightly controlled storage subnet over broad network ranges.
Never expose a no_root_squash export to user networks, general-purpose servers, or untrusted clients.
Use a dedicated filesystem or volume for the datastore when possible, reducing the impact of an incorrect rule.
Review NAS export rules and vSphere datastore assignments together. Each limits a different part of the access path.
Recheck the allowlist when an ESXi host is replaced, readdressed, moved between VLANs, or added to a cluster.

Exam-relevant notes

ESXi NFS datastore access requires both VMkernel-to-NAS connectivity and NAS-side authorization.
NFSv3 over TCP must be supported and selected compatibly by both ESXi and the NAS.
The export path used in vSphere must match the exact path published by the NAS.
All intended ESXi hosts need read-write access to the same export.
root_squash maps client root to an anonymous UID/GID; it can block ESXi file operations.
no_root_squash preserves client root identity and is normally required for the specified ESXi NFSv3 datastore scenario.
no_root_squash is powerful and must be restricted to explicitly authorized ESXi clients or a protected storage network.
Guest operating system permissions are separate from the ESXi host's permissions on the NFS datastore.

For related study, see NFS access controls.