VMware ESXi and vSphere Cluster Management

NFS Datastores for VMware ESXi: Overview, Components, and Requirements

Learn how ESXi uses NFS 3 datastores, including NAS architecture, exports, permissions, VMkernel networking, shared storage, mounting, and troubleshooting.

Network File System (NFS) is a protocol for accessing shared files across an IP network. VMware ESXi includes an NFS client, allowing an ESXi host to connect to file-based storage exported by an NFS server or NAS device.

In the environment described here, ESXi uses NFS version 3. The administrator supplies the NFS server address and the server-side export path when adding the storage to ESXi. ESXi then mounts the export and presents it as an NFS datastore.

What NFS Means for ESXi

NFS stands for Network File System. It is a network file-sharing protocol: a server makes a directory available, and an authorized client accesses that directory as remote file storage.

For ESXi, the server is commonly a specialized network-attached storage system called a NAS. The NAS provides file-sharing services, manages the underlying disks or file systems, and exports selected directories to authorized clients. The ESXi host acts as the NFS client.

NFS is different from block-based storage at a high level:

File-based NFS storage: The NAS presents an exported directory and manages the file system. ESXi accesses virtual machine files through NFS.
Block-based storage: A storage system presents block devices or logical units to ESXi. ESXi commonly formats or manages those devices with VMFS.

Both models can store virtual machine workloads. The access model and storage responsibilities are different. Detailed iSCSI, Fibre Channel, multipathing, and VMFS configuration are separate subjects.

NFS Storage Architecture for ESXi

An ESXi NFS design contains several cooperating components:

Component	Role	Key requirement
ESXi host	Runs virtual machines and uses the ESXi NFS client to access shared files.	Must be authorized to use the export.
VMkernel storage adapter	Provides the ESXi network interface used for storage traffic.	Must have correct IP, VLAN, routing, and storage-service configuration.
TCP/IP storage network	Carries NFS requests and responses between ESXi and the NAS.	Must provide reliable connectivity and consistent MTU settings.
NAS/NFS server	Hosts the file system and provides the NFS service.	Must have an active service and an appropriate export policy.
NFS export directory	Server-side directory made available to NFS clients.	Must exist and allow the required ESXi access.
NFS datastore	ESXi inventory object backed by the mounted NFS export.	Should be mounted and accessible on every required host.

The communication path is:

An ESXi host sends an NFS request through its VMkernel storage adapter.
The request travels across the TCP/IP storage network to the NAS or NFS server.
The NFS server checks the client authorization and export permissions.
The server reads or writes files in the exported directory.
The response returns to ESXi, which exposes the remote file storage as a datastore.

Understanding the NFS Datastore

An NFS export is not automatically an ESXi datastore just because it exists on the NAS. ESXi must mount the export and register it as a datastore. The resulting object is an NFS datastore.

Administrators use an NFS datastore much like a VMFS datastore for virtual-machine placement. It can appear in the datastore inventory, contain virtual machine files, and be selected when creating or moving workloads.

In a cluster, the same export should be mounted on every ESXi host that needs shared access. Mounting the identical export gives participating hosts access to the same files rather than creating separate, host-specific storage views.

A datastore name is administrative metadata. For example, an administrator might name the datastore My NFS Datastore. That name is separate from the NFS server's export path, such as /exports/esxi-production. Changing the inventory name does not change the server-side directory.

Recognizing NFS 3 in the interface

When the described implementation is added, the ESXi or vCenter management interface identifies the datastore type or file system view as NFS 3. This label helps distinguish the datastore from VMFS and other storage types.

NFS versions do not all have identical configuration, capabilities, or security behavior. Do not assume that instructions for NFS 3 apply unchanged to every newer NFS implementation.

Files Stored on an NFS Datastore

An NFS datastore is a repository for files used by ESXi and its virtual machines. Depending on placement and configuration, it can contain:

Virtual machine configuration files.
Virtual machine virtual disk files.
Virtual machine logs.
Snapshot-related files.
Virtual machine swap files when they are configured to reside on the datastore.
Virtual machine templates.
ISO images and other installation media.
Other datastore-resident administrative or application files.

For example, a small cluster might use one export for production virtual machines and another for templates and installation media. A common ISO and template repository avoids maintaining separate copies on each host.

Why Shared NFS Storage Matters

Common access to the same datastore is especially important in a multi-host cluster. If a virtual machine's configuration and disk files are available to every compatible host, a host other than the current owner can access those files when a cluster operation requires it.

vMotion: Live migration of a running virtual machine generally requires the destination host to access the virtual machine's storage. Shared NFS storage can provide that common access.
DRS: Distributed Resource Scheduler can make placement and migration decisions across hosts. Shared storage helps hosts use the same virtual-machine files during those operations.
HA: VMware High Availability can restart affected virtual machines on another host after a host failure when that host can access the required files on the shared datastore.

Preparing the NFS Server

Before configuring ESXi, prepare the NAS or NFS server:

Create a dedicated directory or file-system location for the ESXi datastore. A separate volume or directory can simplify capacity management and access control.
Enable the NFS service on the NAS server.
Export the directory through the server's NFS export configuration.
Authorize the intended ESXi host IP addresses, storage subnet, or explicit host definitions in the export policy.
Grant read and write access and configure the root access behavior required by ESXi.
Record the NFS server name or IP address and the exact export path. The path is supplied when the datastore is added to ESXi.

Example server details
NFS server: 192.0.2.50
Export path: /exports/esxi-production
Authorized clients: ESXi storage-network addresses
Access: read/write with appropriate ESXi root access

The example values are illustrative. Use the address, path, and export syntax supported by the particular NAS platform.

Permissions and Root Access

ESXi requires read and write access to the exported directory so it can create, modify, and remove datastore files as permitted by the operation. A read-only export may mount successfully but fail when ESXi attempts to create a virtual machine folder, upload an ISO, or write a configuration file.

For NFS datastore access, ESXi accesses the export using the root account identity. The NFS server export policy must therefore allow the authorized ESXi hosts root read/write access as required by the implementation.

Root squashing

Root squashing is an NFS server behavior that maps remote root access to a less-privileged identity. It is a security control intended to prevent a remote root user from receiving unrestricted server-side privileges.

However, if root access from ESXi is squashed or mapped to an identity without suitable permissions, ESXi may be unable to create or modify datastore files. A datastore might appear to mount while write operations fail.

Configure the NAS according to its security model and the supported ESXi requirements. Limit the export to authorized ESXi hosts rather than broadly allowing every client on the network. Review both the NFS export policy and the underlying directory permissions.

For related access-control concepts, see Access Controls in NFS.

Network Requirements

Every participating ESXi host needs IP connectivity to the NAS or NFS server. Storage traffic should use a VMkernel adapter configured for the storage network. The adapter may be connected to a dedicated storage VLAN or port group, depending on the network design.

IP addressing: Use valid addresses and masks on the ESXi storage interfaces and NAS interfaces. Host names can be used when DNS is reliable; IP addresses can make dependencies more explicit.
Routing: Ensure the storage network has a valid path between each ESXi host and the NFS server. Asymmetric or missing routes can prevent mounting or cause unstable access.
VLAN configuration: Confirm that switch ports, port groups, trunks, and NAS interfaces carry the intended storage VLAN.
MTU: If jumbo frames are used, configure a consistent MTU across the complete path, including ESXi, switches, routers where applicable, and the NAS. A partial jumbo-frame configuration can cause failures or intermittent behavior.
Firewall reachability: Firewalls and security controls must permit the NFS traffic required by the selected NFS implementation.
Reliability and latency: Production storage networks should be reliable, low-latency, and designed with suitable redundancy.

All hosts that participate in shared-storage operations must have consistent access to the same export. A storage path available to only one host is not equivalent to shared storage for the cluster.

High-Level NFS Datastore Mounting Workflow

Prepare the server: Create the directory or file system location and export it through the NFS service.
Configure authorization: Allow the intended ESXi host addresses and grant the required read/write and root access.
Validate networking: Confirm the storage VMkernel adapter, VLAN, routing, MTU, DNS or IP choices, and firewall reachability.
Verify every host: Check reachability and export authorization from each ESXi host that will use the datastore.
Add the datastore: In ESXi or vCenter, choose the option to add an NFS datastore, select NFS version 3 for this implementation, enter the server address and exact export path, and assign a meaningful datastore name.
Mount consistently: Mount the same export on every host that requires shared access.
Validate use: Confirm that the datastore is visible, browse it, and perform a permitted write test before placing production workloads on it.

Prerequisites Checklist

Requirement	Why it matters	Validation approach
NFS server reachable from each host	Mount and file operations require network connectivity.	Check storage-interface addressing, routing, and reachability.
NFS service and export enabled	ESXi cannot mount an inactive service or unexported directory.	Review NAS service status and export configuration.
Correct export path	ESXi must identify the exact server-side directory.	Compare the path entered in ESXi with the active NAS export.
Host read/write authorization	Virtual-machine and datastore files require write operations.	Review the export client list and access mode.
Root read/write access permitted	ESXi uses the root identity when accessing the export.	Check root mapping, root squash, and directory permissions.
Consistent storage-network configuration	Differences in VLAN, MTU, routing, or firewall policy can isolate hosts.	Compare the VMkernel and network settings on all hosts.
Datastore mounted on each required host	Shared operations require common visibility.	Inspect datastore inventory and accessibility on every host.

NFS and VMFS: High-Level Comparison

Characteristic	NFS datastore	VMFS datastore
Storage access model	File-based access through the NFS protocol.	Block-device access managed by VMware's clustered file system.
Underlying storage source	A directory exported by an NFS server or NAS.	Typically a block storage device or logical unit presented to ESXi.
Host presentation	Each host mounts the export as an NFS datastore.	Hosts discover and use a VMFS volume on shared block storage.
Typical protocol context	NFS over a TCP/IP network.	Block protocols such as iSCSI or Fibre Channel, depending on the design.
Virtual machine file storage use	Stores virtual machine files, templates, ISOs, and related files.	Also stores virtual machine files and related datastore content.

This comparison establishes the boundary between file-based NFS and block-based VMFS. Detailed block-storage design and multipathing belong in follow-on storage lessons.

Practical Example: One NFS Datastore for Three Hosts

A NAS server exports /exports/esxi-production. Three ESXi hosts have VMkernel storage adapters on a storage VLAN that can reach the NAS. The NAS export policy authorizes the three host addresses, grants read/write access, and permits the root access behavior required by ESXi.

An administrator mounts the identical export on all three hosts and assigns it the inventory name My NFS Datastore. The management interface identifies its type as NFS 3. Virtual machines, templates, ISO files, logs, and other permitted files can then be accessed through the shared datastore by the participating hosts.

If the export is mounted on only two hosts, the third host does not have equivalent shared access. That host must be checked for network authorization and must mount the same export before it is treated as a participant in shared-storage operations.

Common Symptoms and First Checks

Symptom	Likely cause	First checks
Mount operation fails	Wrong server address or path, inactive NFS service, missing authorization, or blocked network traffic.	Verify the exact path, service status, VMkernel networking, VLAN, routing, firewall, and export policy.
Datastore visible on only one host	The datastore was not mounted everywhere, or some hosts lack network access or authorization.	Compare mounts, VMkernel settings, host addresses, and NAS client permissions.
Datastore becomes inaccessible after network changes	Changed VLAN, route, MTU, DNS, firewall, or switch configuration.	Compare the working and affected paths end to end.
Unable to create or upload files	Read-only export, restrictive directory permissions, or root squashing.	Check export read/write mode, directory permissions, and root mapping.
Intermittent storage access	Unreliable network path, MTU mismatch, congestion, or insufficient redundancy.	Check link health, errors, latency, MTU consistency, and storage-network redundancy.

Permission failure after a successful mount

If the datastore mounts but ESXi cannot create a virtual machine folder or upload a file, mounting proves only that basic access succeeded. It does not prove that the server will permit every required write operation.

Confirm that the export is read/write rather than read-only.
Review the server-side directory and file-system permissions.
Check whether root access is being squashed or mapped to an identity without write permission.
Repeat a controlled read/write validation before placing production workloads on the datastore.

Cluster inconsistency

If only some cluster hosts can access the datastore, compare the hosts rather than changing the working host first. Verify the datastore mount, VMkernel IP configuration, VLAN, MTU, routing, firewall reachability, and NAS export authorization for every host.

Shared feature failure

If vMotion, DRS, or HA does not work as expected, first verify that every participating host can see and read the required virtual-machine files. Then check the feature's separate vMotion, DRS, HA, compatibility, licensing, and cluster prerequisites. Shared NFS access is one requirement, not the complete feature configuration.

Exam-Relevant Notes

NFS is a file-based network storage protocol; VMFS is VMware's clustered file system generally associated with block storage.
ESXi acts as the NFS client, while the NAS or NFS server hosts and exports the directory.
An NFS export becomes an NFS datastore after ESXi mounts it.
Use the same export on every ESXi host that needs shared access.
The described implementation uses NFS 3, which appears as NFS 3 in the datastore type or file-system view.
ESXi requires suitable read/write access and root access behavior; root squashing can prevent datastore writes.
A VMkernel adapter and end-to-end TCP/IP connectivity are required for storage traffic.
vMotion, DRS, and HA also require broader vSphere configuration, compatibility, licensing, and healthy networking.

For broader ESXi administration practice, see the VMware ESXi Online Course. Related subjects include datastores in Virtual SAN and vSphere HA admission control.