Proxmox VEVII · Shared StorageNFS
NFS in Proxmox
What you'll learn
- Add an NFS share to Proxmox as a storage backend
- Choose appropriate NFS versions and mount options
- Recognise the failure modes of NFS-backed VM storage
- Tune NFS for performance
Prerequisites
Verified against Proxmox VE 9.2.4 · Proxmox Backup Server 4.2.5 · Ceph Squid / Tentacle · Debian 13 (Trixie) · Linux kernel 7.0 (PVE 9.2 default) · 2026-08-07
Why this matters in production
NFS is the simplest shared-storage option in Proxmox. It is also the easiest to misconfigure in ways that hurt performance or availability. This lesson teaches the configurations that work.
When NFS is appropriate
NFS is a good fit when:
- You already have a competent NFS server (enterprise NAS, NetApp, etc.).
- The workload does not need the IOPS of block storage (file shares, archives, ISO storage, low-IOPS VMs).
- You need a shared filesystem between VMs (CT-to-VM shared volumes).
NFS is not appropriate for:
- High-IOPS VM disks (use iSCSI, FC, or Ceph instead).
- Mission-critical workloads without a backup story.
Adding NFS as Proxmox storage
flowchart LR
A[NFS server] -->|TCP 2049| B[Proxmox nodes]
B --> C[VM disks on NFS]
GUI: Datacenter → Storage → Add → NFS. CLI:
pvesm add nfs nfs-main --server nas01.lab.example.com --export /srv/proxmox --content images,iso,backup --options vers=4.1
Required parameters:
server— NFS server hostname or IP.export— exported path.content— what kinds of content can live here (images, iso, backup, snippets, rootdir, etc.).options— mount options (NFS version, performance tunings).username/password— for authenticated NFS (rare).
Mount options
Common options:
| Option | Purpose |
|---|---|
vers=4.1 | Force NFSv4.1 |
hard | Retry indefinitely on failure (vs soft which returns errors) |
timeo=600 | Timeout per request (6 seconds) |
retrans=3 | Retries before declaring failure |
rsize=1048576 / wsize=1048576 | Read/write block size; 1 MB max in NFSv4 |
noatime | Don’t update file access times |
lookupcache=positive | Cache positive DNS lookups |
Failure modes
| Failure | Symptom |
|---|---|
| NFS server down | VM I/O blocks; HA may not detect this if the network is up but the server is not |
| Network partition | Same as NFS server down for affected nodes |
| Slow NFS server | VM latency spikes, may exceed HA watchdog timeouts |
| NFS server overload | All clients slow simultaneously |
Performance tuning
- MTU: enable jumbo frames end-to-end for large NFS transfers.
- Multiple NICs: use multiple TCP sessions (
mount -o nconnect=4on Linux 5.10+) or LACP bonding. - pNFS: if the server supports it, NFSv4.1 enables parallel access.
- Async writes: only safe if the application does its own durability (rare for VMs).
mount | grep nfs && nfsstat -m
Production considerations
Common mistakes
- Using NFSv3 because “it’s simpler.” NFSv4.1 has better locking and is more robust.
- Soft mounts for VM disks (corruption risk).
- NFS over the same network as Corosync (competes for the same link).
- Believing NAS-style snapshot features are backups (they share the same failure domain).
Key takeaways
- NFSv4.1+ for shared storage; hard mounts for VM disks.
- Dedicated storage network for non-trivial deployments.
- Treat the NFS server with the same care as the cluster.
Knowledge check
Knowledge check · 3 questions
Q1. Which NFS version is recommended for Proxmox VM storage?
Q2. VM disks on NFS should use hard mounts, because a soft mount surfaces an I/O error to the guest as soon as the server pauses.
Q3. Which TCP port does NFS use by default?
Passing score: 75%. Answers are checked in this browser.