Configuring NFS Datastores on ESXi with a Linux Backend

NFS remains a practical way to provide shared storage to VMware ESXi, particularly in a home lab, development environment, or small business where a dedicated SAN is difficult to justify. A Linux server can expose storage from local disks, a RAID controller, ZFS, or a hardware-backed volume while ESXi presents it as a shared datastore.

A reliable design depends on more than creating an export and entering its IP address in vCenter. Network separation, filesystem behaviour, NFS permissions, timeouts, monitoring, and recovery procedures all affect virtual machine performance. Australian administrators should also account for long distances between sites, high summer temperatures, local power costs, and privacy obligations when selecting the platform.

Choose the NFS version and storage design

ESXi supports NFS 3 and NFS 4.1, but they have different operational characteristics. NFS 3 is widely understood, simple to troubleshoot, and commonly used with Linux storage servers. NFS 4.1 provides session trunking, improved locking, and multipathing capabilities, although the Linux configuration and ESXi integration require greater care.

For a first deployment, NFS 3 is often the least surprising choice. NFS 4.1 becomes more attractive when the environment needs multiple storage paths and the team is comfortable validating identity, locking, and failover behaviour. Avoid mixing protocol assumptions between hosts, and confirm that every ESXi server uses the same datastore configuration.

The backend should use a dedicated filesystem or logical volume rather than sharing a general-purpose Linux directory with unrelated workloads. Hardware RAID, ZFS, or enterprise SSDs can improve resilience, but they do not replace tested backups. For a home lab connected through the NBN, keep storage traffic inside the local network; consumer internet links are unsuitable for datastore I/O.

Prepare the Linux storage server

Install the NFS server packages supplied by the Linux distribution. On Debian or Ubuntu, this is typically nfs-kernel-server; Red Hat-based systems use nfs-utils. Create a mount point such as /srv/vmware/nfs01, mount the underlying storage, and add it to /etc/fstab using a stable UUID rather than a device name that may change after a reboot.

Use a filesystem and mount options appropriate for virtual machine workloads. Ext4 and XFS are common choices, while ZFS can provide snapshots and integrity checks when it is properly designed. Leave sufficient free capacity for metadata and snapshots, and monitor latency rather than relying only on throughput figures.

The Linux host should have a predictable hostname and a static address. Configure DNS and reverse DNS where possible, then verify name resolution from both the storage server and ESXi. In Australian offices, storage may sit in a Brisbane server room while administrators manage it from Sydney or Melbourne; clear DNS and routing records prevent remote troubleshooting from becoming guesswork.

Configure secure NFS exports

Define the datastore export in /etc/exports. A basic NFS 3 example might resemble /srv/vmware/nfs01 192.168.50.0/24(rw,sync,no_subtree_check), with the subnet replaced by the dedicated storage network. The sync option prioritises confirmed writes, while no_subtree_check avoids unnecessary path verification for a dedicated export.

Avoid exporting the datastore to the entire corporate network. Restrict access to the ESXi VMkernel addresses, use a storage VLAN where practical, and apply host firewall rules for NFS and the required RPC services. NFS 3 commonly involves port 2049 plus services such as rpcbind and mountd, so firewall rules must account for the distribution’s service configuration.

Run exportfs -ra after changes and inspect the result with exportfs -v. Do not use no_root_squash simply because it makes permissions easier. Root squashing is a useful security control, and the export should be dedicated to ESXi rather than exposing a directory that contains ordinary Linux files.

Build the ESXi storage network

Create a VMkernel adapter for storage traffic on each ESXi host. Place it on the correct VLAN, assign addresses from the storage subnet, and attach it to a vSwitch or distributed switch with the intended uplinks. Test reachability from every host using ESXi networking tools before attempting to mount the datastore.

Jumbo frames can reduce packet overhead, but only when every switch, NIC, VMkernel interface, and Linux interface supports the same MTU. A partial MTU change creates intermittent failures that can look like NFS instability. Start with standard Ethernet frames unless there is a tested reason to use 9000-byte frames.

Use separate physical paths or NICs when the design requires redundancy. Link aggregation is not automatically equivalent to multipathing, and NFS 3 does not provide the same native multipath model as NFS 4.1. For larger environments, validate the architecture against VMware support guidance before treating a home-lab pattern as an enterprise design.

Mount the datastore in vSphere

In the vSphere Client, select the desired ESXi host or cluster, choose Datastores, and start the New Datastore workflow. Select NFS, choose the correct NFS version, enter the Linux server address, and provide the export folder exactly as it appears in the export table. Give the datastore a consistent name across the cluster.

If the datastore is intended for multiple hosts, mount it to all compatible hosts through vCenter rather than configuring isolated mounts manually. Confirm that each host sees the same UUID and datastore label. A duplicate or stale mount can cause confusing inventory and virtual machine registration problems.

If mounting fails, check the export permissions, Linux firewall, ESXi VMkernel routing, DNS, and NFS service status in that order. A successful ping proves very little; it does not confirm that RPC negotiation or the NFS mount request is permitted.

Validate performance and recovery

Test with a non-production virtual machine before moving workloads. Observe datastore latency, outstanding I/O, CPU wait, and network errors while creating files, powering on guests, taking snapshots, and copying data. A storage server can show excellent sequential throughput while delivering poor results for small random writes.

Reboot the Linux host during a maintenance window and confirm that the storage volume mounts before the NFS service starts. Then test an ESXi host reboot and verify that the datastore reconnects without manual intervention. Check the behaviour of powered-on and powered-off virtual machines, since temporary NFS loss can affect them differently.

Document the recovery process, including export paths, VLAN details, IP addresses, firewall rules, and ownership of the Linux server. If the platform supports snapshots, treat them as a short-term recovery aid rather than a backup. For designs where shared storage resilience is the priority, compare this approach with resilient vSAN design before expanding the cluster.

Operate the platform safely over time

Monitor free space, filesystem health, NFS service availability, network errors, and datastore latency. Set alerts before capacity reaches critical levels; virtual machine snapshots and thin-provisioned disks can consume space much faster than expected. Keep ESXi, Linux, firmware, and storage packages within supported combinations.

Security deserves ongoing attention. The Australian Privacy Act 1988 and the Notifiable Data Breaches scheme may apply when virtual machines contain personal information, so access control, audit records, encryption, and tested recovery procedures should match the data being hosted. Restrict management access and avoid exposing NFS services to the public internet.

Plan for the local environment as well. A Perth shed or a Melbourne garage lab may experience substantial summer heat, while electricity pricing can make always-on enterprise hardware expensive. Refurbished servers are common in the Australian market, but check drive health, replacement availability, warranty terms, and noise before relying on them for production services.

Use a repeatable build record for every host and datastore, and keep configuration snippets in version control. The free tools available from Virtxpert can also support VMware administration and automation tasks around a carefully documented lab.

Build the Linux export, mount it through vCenter, and test failure recovery before placing important workloads on it. A small, repeatable NFS design gives ESXi shared storage without hiding the operational details that keep virtual infrastructure dependable.