Why native zfs on proxmox beats a truenas vm for home labs

At a glance:

• Running ZFS directly on Proxmox avoids PCIe passthrough headaches with the LSI 9207-8i controller.
• Native datasets can be bind‑mounted into LXC containers, eliminating the extra NFS/SMB hop a TrueNAS VM requires.
• TrueNAS still offers a polished GUI and app catalog, but for a single‑host setup Proxmox’s simplicity wins.

Adding NAS to a Proxmox box: the options

Adding network‑attached storage to an existing Proxmox installation can be tackled in several ways. The most common recommendation is to spin up a TrueNAS virtual machine and pass the physical disks through to it. That approach gives you the familiar TrueNAS graphical interface and its built‑in app catalog, but it also introduces a layer of complexity that many hobbyists find unnecessary.

In my home lab I started with an LSI 9207‑8i HBA and a pair of Seagate Exos SAS drives. The initial plan was to hand the controller to a TrueNAS VM via PCIe passthrough, but after wrestling with IOMMU groups and ACS overrides on a Z170‑E motherboard, I decided to let Proxmox manage the disks directly with native ZFS. The result has been a smoother, more reliable stack that required far less time to get right.

Why passing the whole HBA through is a pain point

TrueNAS needs raw, unmediated access to the disks to expose SMART data and to let ZFS enforce its data‑integrity guarantees. In a virtualised environment the only safe way to provide that level of access is to pass the entire HBA controller to the guest OS via VFIO. When the host hands over the card, it loses any ability to touch the attached drives. On enterprise‑grade boards with clean IOMMU isolation this works fine, but on my consumer‑grade Z170‑E the 9207‑8i does not sit in its own IOMMU group by default.

Sorting that out meant diving into ACS overrides, editing kernel parameters, and testing for stability after every reboot. After dozens of hours of troubleshooting, the prospect of maintaining a passthrough layer on top of a storage‑heavy workload felt like an absolute nightmare. By contrast, when ZFS runs natively on the Proxmox host, the controller stays under the host’s control, the pool is created using stable /dev/disk/by-id paths, and there is no need for any VFIO gymnastics.

Seamless data paths with native ZFS and LXC bind mounts

The real breakthrough for me was how easily Proxmox lets you expose ZFS datasets to containers. I created a pool called tank and several datasets such as tank/immich/library and tank/immich/db. Those datasets are then bind‑mounted directly into Immich LXC containers:

• tank/immich/library → /immich/library
• tank/immich/db → /immich/db

Because the datasets live on the host, the containers see the files instantly after the host boots—no NFS or SMB export, no extra service to start, and no extra network hop for every byte. In a TrueNAS‑in‑a‑VM scenario the same data would have to travel out of the VM over NFS or SMB, be re‑mounted inside the container, and then wait for the TrueNAS VM to finish its boot sequence before the application could even start. The native bind‑mount approach eliminates that round‑trip entirely, reducing latency and simplifying the dependency chain.

The TrueNAS GUI and app catalog: a double‑edged sword

TrueNAS shines when you need a single, coherent graphical console for storage management. The web UI bundles pool creation, snapshot scheduling, replication tasks, SMART dashboards, and alerting into one place. For newcomers, those guardrails prevent accidental foot‑guns that a raw CLI might invite. The platform also ships a curated app catalog that can deploy Docker‑Compose workloads with a few clicks, effectively giving you a turnkey NAS‑plus‑applications appliance.

However, that polish comes with a cost. Most of the configuration work is front‑loaded; once the shares and schedules are defined, you rarely touch the UI again. If you are comfortable with the command line, you may find the GUI unnecessary friction. Moreover, TrueNAS deliberately discourages direct CLI interaction with the ZFS pool, which can be limiting for power users who prefer scripting or manual zfs commands.

When native ZFS on Proxmox is the better fit

For my particular setup—a single Proxmox host that also runs Docker containers and LXC services—the native ZFS approach proved to be the simplest architecture. The benefits include:

1. No passthrough layer – the host retains full control of the HBA and disks.
2. Instant dataset availability – bind mounts are ready as soon as the host boots.
3. Reduced points of failure – eliminating a second VM removes a whole stack of potential bugs and boot‑order issues.
4. Full CLI freedom – I can manage the pool, snapshots, and replication directly with zfs commands.

If you are building a dedicated storage box, or you need the polished replication UI and the one‑click app installs that TrueNAS offers, a VM might still make sense. But for a mixed‑purpose home lab where the same host runs both storage and services, native ZFS on Proxmox delivers a cleaner, more maintainable solution.

Looking ahead: scaling and future considerations

Should my lab grow beyond a single node, I will likely explore Proxmox’s built‑in clustering and ZFS replication features. Proxmox can replicate ZFS snapshots to a remote node over SSH, providing disaster recovery without needing a separate TrueNAS appliance. Additionally, the community is actively improving support for NVMe‑based ZFS pools, which could further boost performance for media‑intensive workloads like Immich.

In the meantime, the lesson stands clear: when the storage and compute layers live on the same physical box, keeping ZFS native to the hypervisor sidesteps many of the pitfalls that come with virtualising a full‑blown NAS OS. It’s a decision that saved me countless hours of debugging and gave me a faster, more reliable data path for the applications I care about.