NFS vs iSCSI for a Homelab: Which One to Pick

In the NFS vs iSCSI decision for a homelab, pick NFS by default: it is simpler to set up, the NAS can snapshot and restore individual files, and several hosts can share it safely. Use iSCSI only for a disk one machine owns outright, such as a Docker host’s SQLite app data or a single VM’s disk.

The unglamorous truth for an N100 mini-PC paired with a NAS: the fastest home for VM disks and container databases is usually neither protocol but the mini-PC’s own NVMe, backed up to the NAS. The protocol question gets real when local disk runs out or several hosts need one pool. For the three-way version with SMB, see iSCSI vs NFS vs SMB.

How were NFS and iSCSI compared here?

This comparison draws on two published benchmarks plus vendor documentation from Proxmox, TrueNAS and Synology. Nothing was benchmarked in-house; every number is attributed to whoever measured it. Both benchmarks point the same way: large transfers are a wash, and metadata-heavy work favours iSCSI.

The peer-reviewed one is Radkov et al. at USENIX FAST ‘04. On Linux, with no data shared between machines, they found NFS and iSCSI comparable for data-intensive workloads, while iSCSI led by a factor of two or more on metadata-intensive ones. The authors credit iSCSI’s aggressive metadata caching and aggregation of metadata updates. The paper is 22 years old and predates NFS 4.1, so trust the direction more than the magnitude.

The homelab-scale one, published on enterpriseadmins.org in October 2023, ran Windows 2022 guests under ESXi 8.0u1 on a Synology DS723+ with a single 1Gbps NIC and no SSD, averaging three runs per test. VM power-on took 54.38 s on NFS versus 53.42 s on iSCSI, and a VMware Tools upgrade 89.10 s versus 87.50 s. A robocopy of 66,544 files took 773 s on NFS and 658 s on iSCSI. Same shape as 2004, on hardware much closer to yours.

Why does iSCSI look faster on TrueNAS?

Often because it is doing less work. In jgreco’s long-standing TrueNAS community explainer, “NFS by default will implement sync writes as requested by the ESXi client,” while “iSCSI by default does not implement sync writes. As such, it often appears to users to be much faster.” A fair comparison needs sync=always on the zvol.

TrueNAS’s SLOG documentation points the same way: it recommends a separate log device for “database applications, NFS environments, virtualization, and data backups,” and notes that for iSCSI the zvol Sync setting “can turn asynchronous writes into synchronous.” Any forum chart that omits the sync setting is probably comparing a safe write with an unsafe one. The explainer is ESXi-specific and other initiators handle flushes their own way, so check the setting before trusting any number.

NFS vs iSCSI side by side

Where NFS wins

Anything more than one host touches. The Proxmox NFS docs list NFS as shared storage that can hold images rootdir vztmpl iso backup snippets, so one export becomes your ISO library, vzdump target and template store. Snapshots come from qcow2 because, in Proxmox’s words, “NFS does not support snapshots, but the backend uses qcow2 features to implement snapshots and cloning.”

Backups you can browse. The NAS owns the filesystem, so a ZFS or Btrfs snapshot of an NFS share is a folder of ordinary files. Restoring one config file is a copy, not a project.

Setup time. Synology, which supports both, pitches NFS “for quicker setup and smaller deployments” and iSCSI for “consistently high performance in larger deployments.” That is a vendor page, but a homelab is plainly the smaller deployment.

Two caveats. The Proxmox storage overview warns that internal qcow2 snapshots block a running VM, that performance “is particularly bad with network storages like NFS,” and that large disks can take minutes or, in extreme cases, hours. The sample config on Proxmox’s NFS page also uses vers=3,soft, while the nfs(5) man page warns that a soft timeout “can cause silent data corruption in certain cases.” For VM disks, keep mounts hard: a dead NAS then hangs I/O instead of quietly corrupting it.

Where iSCSI wins

SQLite app data that has to live on the NAS. SQLite’s documentation says some filesystems have buggy locking, “especially true of network filesystems and NFS in particular,” and that concurrent access on one can corrupt a database. The Servarr wiki is blunter: the app-data folder, the /config mount in Docker, “MUST be on local storage.” An ext4-formatted iSCSI LUN is local storage as far as the kernel is concerned, so locking behaves. One LUN per host, though: two machines mounting the same ext4 LUN will destroy it, as the iSCSI fundamentals guide explains.

Small files and metadata. Both cited benchmarks favour iSCSI when a workload creates, renames and stats lots of small files, because the client caches metadata instead of asking the server every time.

MPIO, if you have the NICs. Multipath I/O spreads load and fails over across independent paths. A mini-PC with one NIC has one path, so this advantage is worth nothing until you add a port. NFS on Linux has nconnect, which the man page caps at 16 connections per mount.

The Proxmox catch: raw iSCSI storage has no snapshots or clones, so the Proxmox iSCSI docs recommend exporting one big LUN with LVM on top. Proxmox VE 9 added snapshots as volume chains, but the LVM docs still label them a technology preview. The fully featured route, ZFS over iSCSI, gives each disk its own zvol with native snapshots, but needs passwordless root SSH to the storage box and a target running LIO, IET, istgt or Comstar. TrueNAS is not on that list.

Storage and backups: the month-nine problems

Thin LUNs do not shrink on their own. Deleting files inside an iSCSI-backed filesystem frees space for the client, not the NAS, until the client sends UNMAP. Enable fstrim.timer on Linux hosts and the Discard option on Proxmox virtual disks. The NAS sees NFS deletes directly.

Docker can start before the LUN mounts. Containers then write into the empty mount-point directory on the root disk, and that data seems to vanish once the LUN mounts over it. Mount the LUN with _netdev in fstab and add RequiresMountsFor=/srv/appdata to a systemd drop-in for docker.service.

Run the restore drill once. For an NFS dataset, copy one file out of last night’s snapshot. For a zvol, clone the snapshot, expose the clone as a new LUN, attach it to a different machine, mount it read-only and open a file. The NAS cannot see inside a LUN, so that is your only file-level restore path from NAS snapshots, and a quiet Sunday is the time to learn it. Then replicate snapshots to a second box, because a snapshot on the same pool is not a backup. The TrueNAS iSCSI target walkthrough covers the zvol side, and iSCSI troubleshooting explains why a LUN can go read-only after a NAS reboot.

Which one should you pick?

For one N100 mini-PC and one NAS, use NFS for media, ISOs and backups, keep VM disks and container app data on local NVMe, and add one small iSCSI LUN only if app data must live on the NAS’s redundant pool. That split dodges the SQLite, sync-write and restore traps above with the fewest moving parts.

For two or three Proxmox nodes that want live migration, start with NFS, hard mounts and qcow2, taking big-disk snapshots with the VM shut down as Proxmox advises. Move to iSCSI with LVM only if you want block semantics and accept technology-preview snapshots; otherwise you have built a small SAN to host a Pi-hole. Neither protocol belongs on the internet: keep both on the LAN and reach the NAS remotely over Tailscale or not at all.

Here is that split as a compose file, using the NFS named-volume pattern from Docker’s volume documentation:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config   # local NVMe or an iSCSI LUN, never NFS
      - data:/data                    # media and downloads on the NAS over NFS
    ports:
      - "8989:8989"
    restart: unless-stopped

volumes:
  data:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=192.168.1.20,nfsvers=4,hard,rw"
      device: ":/mnt/tank/data"

FAQ

is nfs or iscsi faster

Neither, for large sequential transfers such as streaming media or copying ISOs, where published benchmarks found the two comparable. iSCSI pulls ahead on metadata-heavy work with many small files, by a factor of two or more in the 2004 USENIX study. On ZFS, check sync settings first, because async iSCSI writes inflate many comparisons.

can two computers use the same iscsi lun

Only if the layer on top is cluster-aware, such as VMFS on ESXi or shared LVM in a Proxmox cluster, which splits the LUN into separate virtual disks. Two machines mounting the same ext4, XFS or NTFS LUN will each cache metadata and overwrite each other’s changes. If several machines need the same files, use NFS.

should i use nfs or iscsi for proxmox

Use NFS for ISOs, container templates and vzdump backups, because Proxmox lets an NFS store hold every content type while iSCSI storage holds only disks. For shared VM disks, NFS with qcow2 is simpler; iSCSI with LVM on top is the block option, with snapshots still a technology preview. On a single node, local NVMe avoids the question entirely.

can docker volumes be on nfs

Yes for media and bulk files, using a named volume with the local driver and NFS mount options, as Docker’s documentation shows. No for anything holding a SQLite database, such as Sonarr’s or Prowlarr’s config folder. SQLite’s maintainers warn that network-filesystem locking can be buggy, and the Servarr wiki requires app data on local storage.

Related across the network

• iSCSI vs NFS for VMware Datastores: Which to Pick — sanstorageguide.com
• What Is a Zvol? TrueNAS Zvol vs Dataset Explained — truenasguide.com