VMware ESXi and vSphere Cluster Management

NFS Access Controls for VMware ESXi Datastores

Learn how to configure NFS export permissions, VMkernel networking, root_squash, and no_root_squash for reliable VMware ESXi NFS datastores.

An NFS datastore is a VMware datastore backed by a file-system export on a NAS server. Each ESXi host mounts the exported path over the network and uses it to store virtual-machine files, including configuration files, virtual disks, logs, snapshots, and lock-related files.

Successful access depends on three layers working together: the ESXi VMkernel network configuration, the NAS export rules, and the NAS file-system identity and permission model. A host may be able to reach the NAS server but still fail to mount the datastore or operate virtual machines if the export denies the host, is read-only, or changes the identity used for ESXi requests.

For related host and storage administration concepts, see VMware ESXi and the VMware ESXi online course.

How NFS Access Controls Work in ESXi

Network File System, or NFS, is a protocol that lets a client use files stored on a remote server. In an ESXi environment, the ESXi host is the NFS client and the NAS system is the NFS server.

The NAS publishes a directory or file-system path as an NFS export. An export is a server-side path made available to selected client addresses or networks. When an ESXi host adds an NFS datastore, it supplies the NAS server address, the exact export path, a datastore name, and a compatible NFS version.

Normal datastore activity requires more than read access. ESXi must be able to create, open, modify, rename, lock, and remove files. For example, creating a virtual machine requires new configuration and disk files; powering it on requires access to those files and associated lock operations; deleting it requires removal permissions.

These operations are affected by:

The source IP address of the ESXi NFS VMkernel interface.
The NAS export client list or network restriction.
Whether the export is read-write or read-only.
How the NAS maps Unix identities such as UID 0.
Underlying directory ownership, ACLs, and NAS security policies.

Prerequisites for an ESXi NFS Datastore

Prepare every participating ESXi host and the NAS before attempting to mount the datastore.

Requirement	Why It Is Needed	How to Validate
VMkernel interface for NFS	ESXi needs a VMkernel network adapter to send NFS storage traffic.	Review the host networking configuration and identify the adapter intended for NFS.
Network reachability	The VMkernel interface must reach the NAS server through the correct VLAN, switches, routes, and firewall policy.	Test connectivity from each host using the intended VMkernel interface, such as `vmkping`.
NAS file system and export	A NAS volume or file system must exist before its path can be exported through NFS.	Confirm the exact server-side export path in the NAS management interface.
Authorized ESXi clients	The NAS must permit the VMkernel IP address or network used by each ESXi host.	Compare every host's NFS VMkernel address with the export client list.
Read-write access	VM creation and normal virtual-machine operation require file changes.	Inspect the export mode and perform a controlled write test.
Root-level access handling	Relevant ESXi NFS operations use a root-level client identity and may require root-preserving export behavior.	Review root mapping, export options, NAS ACLs, and access logs.
Protocol and transport compatibility	The NAS export and ESXi datastore configuration must agree on NFS version and supported transport behavior.	Confirm the selected NFS version and the NAS capabilities.

VMkernel networking

Each participating host needs at least one VMkernel adapter configured for NFS storage traffic. Give the adapter an address on the storage network and ensure its VLAN, physical uplinks, routing, and filtering allow communication with the NAS.

When a datastore is shared by a cluster, configure and test the storage path on every host that must access it. A datastore that works on one host is not sufficient for vMotion, high availability, or other cluster workflows.

NAS preparation

Create or identify a dedicated NAS file system or volume for virtual-machine storage. Export the path that the NAS actually publishes through NFS. A volume name shown in the NAS interface is not necessarily the same as the export path required by vSphere.

For example, a NAS may display a volume named VMStorage while exporting /exports/vmstorage. The path entered in vSphere must be the exported path, not an assumed volume label.

NFS Versions and Transport

The NFS version selected in vSphere must be supported by the NAS and compatible with the export configuration. Legacy configurations commonly use NFSv3 over TCP. NFSv3 is a stateless NFS protocol version and its server, firewall, and client requirements differ from those of newer versions.

NFSv4.1 provides different connection, namespace, and authentication capabilities from NFSv3. Do not assume that an export configured for NFSv3 can be mounted as NFSv4.1, or that firewall rules for one version cover the other.

Before adding the datastore, confirm:

Which NFS versions the NAS supports for the intended export.
Which version the ESXi release and datastore workflow support.
Whether the required TCP ports and related firewall rules are allowed.
Whether the NAS export path and authentication settings match the selected version.

Protocol selection, export configuration, network filtering, and the vSphere datastore settings must be treated as one design. A mismatch can appear as a connectivity failure, an unavailable export, or a permission error.

NFS Export Access Rules

NAS export rules commonly restrict clients by IP address, subnet, host name, or network. Use the source address of the ESXi VMkernel adapter that sends NFS traffic. Authorize every intended ESXi host, not only the first host used during setup.

For a normal VM datastore, the export should provide read-write access. Read-only access allows files to be read but prevents required operations such as creating virtual disks, updating configuration files, writing logs, and removing files.

Keep the export path exact. The path entered when adding the datastore must match the path the NAS exports, including capitalization and any required parent-directory structure.

Root Identity Requirements

UID 0 is the Unix user identifier normally associated with the root account. In relevant NFS operations, ESXi accesses datastore content using a root-level client identity. The NAS must therefore preserve sufficient authority for the authorized ESXi client to perform datastore operations.

This does not mean that every client on the network should receive unrestricted root access. It means that the export design must account for the identity ESXi presents and the way the NAS maps that identity. If the resulting server-side identity lacks access, ESXi may be unable to mount the datastore or manage virtual-machine files.

root_squash Behavior

root_squash is an NFS export setting that maps requests from client UID 0 to an anonymous or otherwise unprivileged server-side identity. Its security purpose is to reduce the authority of a root user on an NFS client. A compromised client should not automatically gain root-level authority over files on the server.

That protection can conflict with ESXi NFS datastore requirements. If the NAS maps ESXi root requests to an anonymous identity, that identity may not be able to create, modify, lock, rename, or remove virtual-machine files.

Export Option	Treatment of Client Root	Effect on ESXi NFS Datastore Operations	Security Consideration
`root_squash`	Maps client UID 0 to an anonymous or nonprivileged identity.	May prevent mounting, VM creation, power-on operations, file changes, locking, or deletion.	Reduces root authority from clients but may be incompatible with the ESXi datastore access model.
`no_root_squash`	Preserves root identity for an authorized NFS client.	Provides the root-level authority that an ESXi NFS datastore may require.	Must be limited to explicitly authorized ESXi addresses or an isolated storage network.

Typical symptoms of unsuitable root squashing include a datastore mount failure, permission-denied messages, failed VM creation, failed power-on operations, or errors while changing virtual-machine files.

no_root_squash Behavior

no_root_squash allows root on an authorized NFS client to be treated as root by the NFS server. An ESXi NFS datastore export may require this setting, or an equivalent vendor-specific option that permits root access for approved ESXi clients.

Use the narrowest possible scope. Prefer individual ESXi VMkernel IP addresses or a tightly controlled storage subnet over a broad corporate network. Grant the permission only to hosts that need to mount and use the datastore. Never apply root-preserving access broadly to workstations, general-purpose servers, or untrusted clients.

A generic Linux-style export example is:

/vmfs_nfs 192.0.2.11(rw,sync,no_root_squash) 192.0.2.12(rw,sync,no_root_squash)

This is an illustrative syntax example only. The path, addresses, synchronization behavior, option names, and supported security model vary between NAS products. Use the vendor's configuration method and confirm the resulting effective export policy.

Secure Export Design

Use a dedicated storage VLAN or an otherwise isolated network for NFS traffic where practical.
Restrict the export to known ESXi VMkernel IP addresses rather than broad ranges.
Grant read-write access only to hosts that need to use the datastore.
Enable root-preserving access only for explicitly authorized ESXi clients when required.
Do not treat no_root_squash as a universal or default setting.
Use NAS-side logging and monitoring to detect denied requests and unexpected clients.
Record export changes through normal change-control procedures.
Review file-system permissions, ACLs, and higher-level NAS policies in addition to the export rule.

Adding and Presenting the Datastore

Create or identify the NFS VMkernel adapter on each ESXi host.
Assign the appropriate IP address, VLAN, uplink, and routing.
Verify that each host can reach the NAS server through the intended storage interface.
Create the NAS file system and export the correct path.
Authorize every required ESXi VMkernel address.
Set read-write access and configure the required root-access behavior.
In vSphere, add an NFS datastore using the NAS server address, exact export path, datastore name, and compatible NFS version.
Confirm that the datastore is mounted and available on every required host.

Validation After Configuration

Validate from every host independently. A successful mount on one ESXi host does not prove that the export authorizes all cluster members.

Test VMkernel-to-NAS reachability using the intended VMkernel interface, such as vmkping where appropriate.
Check the datastore mount state in the vSphere Client or the ESXi host storage view.
Review NAS export and access logs for denied mount or file-operation requests.
Review ESXi logs and task events for NFS, permission, or connectivity errors.
Perform a controlled write test, such as creating a test directory, subject to operational policy.
Deploy or use a test VM to verify configuration, disk, log, and lock-related file operations.
Confirm consistent access on all hosts that will use clusters, vMotion, or high availability.

Common NFS Permission Symptoms

Symptom	Likely Cause	Validation Step	Typical Correction
Datastore cannot be mounted	Unreachable NAS, incorrect server or export path, unauthorized client, incompatible NFS version, or blocked traffic.	Test VMkernel connectivity; verify the exact export path, source IP, protocol, and firewall policy.	Correct networking or path details, authorize the host, and align the NFS version and transport settings.
Permission denied during VM operations	Root squashing, restrictive ACLs, or insufficient underlying file-system permissions.	Inspect NAS identity mapping, ACLs, export rules, and logs.	Provide the required root access for authorized ESXi clients and correct NAS-side permissions.
Datastore mounts on one host but not another	The second host's VMkernel address is not authorized or uses different network settings.	Inventory every host's source IP and test each storage path.	Add the missing authorized address and correct VLAN, route, uplink, or firewall differences.
Export is visible but write operations fail	The export is read-only or the effective server-side identity is unprivileged.	Check export mode, root mapping, ACLs, and a controlled write test.	Change to read-write and configure appropriate root-preserving access for approved hosts.

Troubleshooting Workflow

The NFS datastore cannot be mounted

Confirm the NFS VMkernel adapter is present, enabled, and using the expected source address.
Check VLAN assignment, physical connectivity, routing, and network filtering.
Test reachability from each host to the NAS server.
Verify the exact export path rather than relying on the NAS volume name.
Compare the host's source IP with the NAS export client list.
Confirm that the NFS version and transport selected in vSphere match the NAS configuration.
Review NAS and ESXi logs for denied mount requests.

The datastore mounts but VM operations fail

Confirm that the export is read-write.
Check whether root_squash maps ESXi UID 0 to an anonymous identity.
Review the resulting identity's directory ownership, ACLs, and file-system permissions.
Check for a NAS policy that is more restrictive than the visible export rule.
Configure root-preserving access for only the authorized ESXi clients when required.
Retest a controlled VM file operation and monitor NAS and ESXi logs.

Only some cluster hosts can access the datastore

Inventory the NFS VMkernel IP address on every host. Compare those addresses with the export rule, then test connectivity and datastore write access independently. Also compare VLANs, routes, uplinks, and host-specific firewall settings. The datastore should not be considered ready for shared-cluster use until every required host has consistent access.

Exam-relevant note: root_squash maps client root to an anonymous or unprivileged identity, while no_root_squash preserves root for an authorized client. ESXi NFS datastore operations may require the latter or an equivalent NAS setting, but it must be tightly restricted to trusted ESXi storage clients.