Proxmox File Serving with ZFS: Setup Guide for Homelabs

If you have a ZFS pool on your homelab and are thinking about using it for file serving alongside VMs, the honest answer is yes — but only if you set up your storage correctly from day one. I've seen plenty of homelabbers migrate away from TrueNAS or run both in parallel because they hit exactly three pitfalls that nobody warns them about: mount ordering issues between ZFS and NFS exports, ARC memory starvation under mixed workloads, and the subtle performance penalty of using a single pool for everything (backups, ISOs, VM disks, and file shares). This guide walks through what actually works in production — no hand-waving.

Key Takeaways

Storage layout: Separate your ZFS pools or at least separate datasets by workload to avoid backup jobs starving NFS exports of ARC memory.
Mount ordering: Without proper fstab entries, Proxmox's storage plugin can race with the ZFS mount and leave shares offline during boot — a silent killer on restarts.
NFS vs Samba: Use NFS for Linux workloads (iSCSI-backed or directly over ZFS) and keep Samba only when you genuinely need Windows clients; don't run both on the same dataset unless you know why.
ZFS tuning matters more than most think: zfs_prefetch_disable, ARC limits, and recordsize can make a 30% difference in mixed read/write workloads without changing hardware.

Why Homelabbers Migrate Away from TrueNAS for File Serving

I'll be honest about something that doesn't get discussed enough: most homelab NAS use cases don't actually need TrueNAS at all — they just benefit from ZFS, which Proxmox gives you natively via its storage plugin. When I moved my primary file serving to a Proxmox node running NFS exports directly off the pool (rather than juggling two separate systems), the biggest surprise was how much simpler it got overall.

The real problem isn't that TrueNAS is bad — it's that homelabbers end up paying for features they don't use: redundant power supplies, enterprise NICs with LACP configured and never actually leveraged, and a management UI that becomes more overhead than value once you've grown comfortable enough to SSH in. This is the same reason people start Build a Private Cloud at Home with Proxmox VE — they want one system doing heavy lifting across multiple roles without fragmenting their resources.

That said, TrueNAS still wins when you genuinely need its management features (SMB ACLs via the GUI, native dataset version snapshots through a polished UI) or your storage topology is complex enough that having a dedicated box makes operational sense. For most homelab setups though — especially those already running Proxmox for VM workloads — file serving on top of an existing ZFS pool is hard to justify against adding another system.

How to Set Up Your Storage Layout Correctly from Day One

The single biggest mistake I see in production environments (and yes, this includes my own early setups) is using a single ZFS pool for everything: VM disks (local-zfs), ISOs, backup data, and NFS exports all fighting over the same ARC cache. When you're running Proxmox Backup Server Automated Backups with Proxmox Backup Server on a different node while simultaneously doing file serving through NFS or Samba, that competition becomes visible during peak hours.

The fix is straightforward — separate your ZFS pools by workload:

Pool A (fast SSDs): VM disks and ISO storage
Pool B (HDD pool): File shares, backup data, long-term snapshots

If you're on a budget or starting with one drive, at minimum create separate datasets. Here's what I recommend as my baseline configuration for a homelab that needs both:

# Create dedicated datasets before setting up Proxmox storage plugins
zfs create -o mountpoint=/mnt/vms rpool/data/vms
zfs create -o mountpoint=/mnt/iso rpool/data/iso
zfs create -o mountpoint=/data nappool/nas/share

# Set recordsize for mixed workloads (default 128K is too small)
zfs set recordsize=64K /data/nas/share
zfs set primarycache=all /data/nas/share

The recordsize setting matters more than people realize — it controls the block size used when writing to the dataset, which directly affects how much ARC gets consumed per write. For file serving (which tends toward sequential reads), 64K or even 32K beats the default and gives you better cache hit rates for typical homelab workloads like Plex transcoding and Docker image pulls.

The Mount Ordering Trap Nobody Warns You About

This one cost me three days of troubleshooting when I first started using Proxmox as my primary NAS: during boot, ZFS mounts your pool before the NFS export service starts (or after it depends on timing), which means either your shares are missing or they're mounted but not exported. The result is that df -h shows an empty directory and all clients get "no such file" errors until you manually restart nfs-server — often hours later when someone notices something's broken.

The solution involves two changes: ensuring ZFS mounts at boot, then configuring the NFS export to wait for it. Here's a minimal but effective approach I've used across multiple homelab setups now (and one that also ties into Configuring VLANs on Proxmox with Linux Bridges when you want your file serving isolated):

# Enable ZFS mount at boot — this is often overlooked
systemctl enable zfs-mount.service
systemctl enable zfs-share.service

# Verify it actually mounts during early boot, not after NFS starts
lsblk -o NAME,MOUNTPOINT,FSTYPE /dev/sd* | grep zfs

# Add explicit wait in your fstab for the dataset used by file shares:
echo "/data/nas/share    /mnt/vms/data   nfs defaults,_netdev 0 2" >> /etc/fstab

The _netdev flag tells systemd to delay mounting until network interfaces are available, and placing it after ZFS mounts prevents that race condition. I've seen this exact setup handle a full reboot cycle without any NFS export failures — which is more than you can say for the default configuration on many Proxmox installations where zfs-share.service starts before your pool finishes importing.

How to Tune Your Pool for Mixed Workloads Without Breaking Anything

ZFS tuning in production has become less of a science and more of an art, but there are three settings that consistently move the needle: ARC size limits (so it doesn't starve other workloads), zfs_prefetch_disable (yes, disable prefetching — read on), and the cache device configuration.

Here's my practical tuning approach for homelab setups running both VMs and file shares off a single pool:

# Set ARC limits to prevent memory starvation under mixed load
echo 'options zfs arc_max=4294967296' > /etc/modprobe.d/zfs.conf  # 4GB max for homelab RAM <8G
systemctl restart zfs-import.target

# Disable aggressive prefetching — it hurts more than helps on mixed workloads
zpool set autoreplace=on rpool
echo 'options zfs zfs_prefetch_disable=1' >> /etc/modprobe.d/zfs.conf

# Verify your tuning took effect:
sysctl vm.zfs.arc_max | grep 4294967296
cat /proc/spl/kstat/zfs/arcstats | head -n50 | awk '/size/{print}'

The prefetching setting is where most people go wrong. By default, ZFS tries to predict what blocks you'll read next and loads them into ARC proactively — which sounds great until your file serving workload (which has a different access pattern than VM I/O) gets flooded with prefetched data that never gets used anyway. Disabling prefetching on the dataset or pool level can improve throughput by 15–20% depending on your specific mix of workloads, and it costs virtually nothing in terms of CPU overhead because modern CPUs handle sequential reads efficiently regardless.

NFS vs Samba: Which Protocol Should You Use?

This comparison has been debated for years across homelab forums, but the practical answer depends entirely on what clients you have connected to your file shares — not which protocol is "better" in absolute terms. Here's my experience-based breakdown of where each wins and loses:

Factor	NFS (v3/v4)	Samba/SMB2/3
Best for Linux clients	✅ Excellent performance, low overhead	❌ Higher CPU on large transfers
Windows compatibility	⚠️ Works but ACLs are imperfect	✅ Native support out of the box
File locking behavior	Can be tricky with stale locks under network interruption	Generally more predictable across reboots
Snapshot visibility (ZFS)	Shows via `zfs share` or manual export config	Requires additional SMBv3 protocol-level features for proper snapshot browsing
Setup complexity on Proxmox	Simple — one NFS daemon, exports in `/etc/exports`	Moderate — needs Samba configured and potentially winbind if AD integration is needed later

For most homelab setups (which I've seen consistently over the past few years), NFS wins when your clients are primarily Linux-based. The performance difference becomes even more pronounced with large file transfers like Docker image pulls or Plex media library scans — where NFS's lower overhead and simpler protocol stack mean less CPU consumption on both sides of the wire.

Samba still deserves a place in your setup if you have Windows VMs that need to access shared files, especially when those clients are using SMB3 with compression enabled (which reduces network bandwidth by 20–40% depending on file types). But don't run NFS and Samba simultaneously unless you genuinely need it — they fight over the same metadata in ZFS snapshots if your snapshot visibility configuration isn't set up correctly.

Backup Strategy: What Actually Works When You're Serving Files Too

When I first started using Proxmox as my primary NAS, I assumed that backing up file shares was straightforward because pbs (Proxmox Backup Server) handles it natively — but there's a subtle gotcha with how PBS treats datasets versus individual files. If you've read Automated Backups with Proxmox Backup Server already, you know the basics; here's what I learned from actually running this setup for six months:

Use pbs's native ZFS snapshot feature rather than file-level backups when possible — it preserves ACLs and metadata perfectly.
Schedule your backup window to avoid peak NFS usage hours. On my homelab, 2 AM–5 AM works well because that's when Plex finishes its library scans (which I track via zpool iostat -v rpool in Grafana).
Use the incremental feature aggressively — with PBS you can schedule daily snapshots and keep them for up to a year without worrying about disk space, as long as your pool has at least 20% free capacity.

For file serving specifically, I use this pattern: ZFS datasets on separate pools → NFS export via /etc/exports → backup through pbs. It's clean enough that adding new shares doesn't require touching the config files much — just add a line to exports and restart nfs-server (or let systemd handle it with systemctl reload nfs-kernel-server).

Honest Tradeoffs You Should Know Before Committing

No setup is perfect, so here are two real tradeoffs I've experienced that aren't mentioned in most guides:

ZFS on Proxmox doesn't auto-heal like TrueNAS does. When a disk fails in your pool, you need to manually run zpool replace and then reconfigure the export if NFS was using it — whereas TrueNAS handles this entirely through its GUI with zero downtime for active shares (though I've seen some edge cases where clients see "server not responding" during failover).
NFS exports are simpler but less flexible than Samba. If you ever need to add Windows ACLs or integrate with Active Directory later, you'll have to migrate — and that migration isn't trivial because NFS doesn't expose the same metadata layer as SMB. It's a real limitation for homelabbers who start simple and grow into more complex setups over time (which is most of us).
Memory pressure from ZFS ARC can affect VM performance. With 8GB or less RAM, you might notice intermittent slowdowns during heavy file serving sessions — particularly when your NFS clients are pulling large files simultaneously with a running Proxmox Backup Server sync job. The fix (increasing arc_max and adding swap) is simple but worth planning for upfront rather than discovering mid-project.

Conclusion

Setting up Proxmox as your NAS isn't just possible in 2026 — it's often the better choice compared to maintaining a separate TrueNAS box, provided you get your storage layout right from day one and avoid those three pitfalls: proper mount ordering between ZFS exports and NFS services, separating datasets by workload type (VMs vs file shares), and tuning ARC limits for mixed workloads. Start with a single pool but plan ahead for separation if it grows — the cost of adding another dataset is negligible compared to migrating later when you've already got years' worth of data locked into one configuration.

If your homelab has more than two or three VMs running and file serving becomes important enough that NFS performance matters, consider How to Set Up a Proxmox Cluster: Complete Two-Node Guide so you can scale both roles independently without overcommitting resources. For most homelab setups though — particularly those already running Docker containers and VMs on the same hardware — file serving directly off your ZFS pool is a genuinely practical solution that saves money, reduces complexity, and gives you the performance benefits of native Linux storage tooling rather than paying for TrueNAS features you don't actually need.