Why Proxmox Won (Over TrueNAS, Unraid, and Bare Metal Docker)

The Decision That Wasn’t a Decision

Last article ended with a dilemma: TrueNAS SCALE on the i5-6500 + Proxmox on the Ryzen — storage-first OS vs virtualization-first OS. I chose virtualization-first. Here’s the full evaluation.

When I started this homelab, I didn’t just pick Proxmox because someone on Reddit said so. I researched what OS would give me VMs, containers, and native ZFS — all on consumer hardware. Proxmox was the only one that checked every box.

Six months later, I can tell you exactly why the others would have failed for me. Not because they’re bad — because they didn’t fit the constraints I didn’t know I had.

The Contenders

Option	What It Is	Why I Considered It
Proxmox VE	Debian-based hypervisor (KVM + LXC)	Free, ZFS native, VMs + containers
TrueNAS SCALE	Debian-based NAS OS (KVM + Docker apps)	ZFS-first, beautiful UI, "apps" for Docker
Unraid	Proprietary OS (KVM + Docker)	Parity array, great Docker UX, GPU passthrough
OpenMediaVault	Debian + web UI for NAS services	Familiar, runs on bare metal
Bare Metal Debian + Docker	Just Linux, no hypervisor	Simplest, maximum performance

Spoiler: I evaluated all five. I installed three. I broke things on two. You’re reading the post-mortem of the one that survived.

TrueNAS SCALE: The One I Evaluated Later (And Almost Switched To)

I wanted this to work. The UI is gorgeous. ZFS is first-class. The "Apps" catalog (Docker containers with pre-built configs) would have saved me weeks of Portainer stack writing. I genuinely considered wiping Proxmox and starting over.

The problem: By the time I evaluated TrueNAS, I already had Proxmox installed with ZFS running on the host (/tank — 3×2 TB RAID-Z). Sunk cost fallacy is real, but so is "I don’t want to re-terraform my storage layer at 11 PM on a Tuesday."

To run TrueNAS, I had two options:

Option A: TrueNAS as VM on Proxmox (ZFS-on-ZFS)

Proxmox Host (ZFS /tank)
    └── TrueNAS VM (virtual disk on /tank)
            └── TrueNAS creates ITS OWN ZFS pool inside the virtual disk

Problems:

Double ARC — both Proxmox and TrueNAS cache the same data in RAM (your RAM is now fighting itself)
Double checksumming — CPU overhead for zero gain (your CPU calculates checksums twice for the same data)
I/O latency — virtual disk → Proxmox ZFS → physical disk (the long way around)
No direct disk access — TrueNAS can’t manage SMART, can’t spin down drives (it’s managing a virtual disk, not real hardware)
Complexity — two ZFS layers, two snapshot systems, two send/receive configs (twice the debugging fun)

I tested this. fio benchmarks showed 30–40% write latency increase. For a NAS, that’s unacceptable. Also my RAM usage chart looked like a heart monitor during a panic attack.

Option B: TrueNAS Bare Metal (Pass Through Disks)

TrueNAS Host (ZFS /tank)
    └── Proxmox VM (for other workloads)

Problem: TrueNAS SCALE’s VM management (via libvirt/KVM) is… functional but not Proxmox. No LXC. No integrated backup. No HA. GPU passthrough works but feels bolted on.

The real issue: I need Proxmox for the other workloads (Home Assistant, AdGuard, Docmost, Immich, n8n). Running Proxmox inside TrueNAS defeats the purpose.

Unraid: The Parity Temptation

Unraid’s "parity drive + data drives" model is brilliant for mixed drive sizes. Add a 4 TB drive to a 2 TB array? No rebalancing. Just works. It’s the storage equivalent of "sure, throw whatever you have in there."

Why not:

Proprietary — $129+ for Plus/Pro, license tied to USB stick (lose the stick, lose your array — great threat model)
No native ZFS — ZFS support is via plugin (Unraid 6.12+), not first-class
Community toxicity — question the license model on forums, see what happens (I’ve seen friendlier shark tanks)
LXC? No. Only KVM VMs + Docker. Home Assistant in a VM is heavier than LXC.
Single parity drive = single point of failure during rebuild. RAID-Z1 survives one drive death; Unraid parity survives one… but rebuild is all remaining drives reading at once.

For a homelab with mixed drive sizes and growth plans, Unraid makes sense. For my 3×2 TB identical drives? RAID-Z is cleaner. Also I refuse to pay a subscription for the privilege of managing my own hard drives.

OpenMediaVault: The Familiar Stranger

OMV runs on bare metal Debian. Web UI for Samba, NFS, Docker (via Compose plugin), users, disks.

Why I tried it: I know Debian. I know Samba. It should "just work." Famous last words.

What broke me:

ZFS plugin is abandoned — doesn’t support ZFS 2.2 features, no RAID-Z expansion, no native encryption UI (the plugin maintainer ghosted ZFS 2.0)
Docker Compose plugin — works but feels like "Portainer lite" without the polish
No VM management — need separate libvirt/virt-manager setup
Permission model — the sharedfolders abstraction fights with direct bind mounts (OMV wants to be your permission manager; ZFS wants to be your permission manager; they argue)

I spent three days on OMV ZFS permissions. Switched to plain Debian + Webmin + Samba. Never looked back. Sometimes the "easy" path is just the long way around to the same destination.

Bare Metal Debian + Docker: The Purist Path

Debian 12 (bare metal)
    ├── ZFS (kernel module)
    ├── Samba
    ├── Docker + Portainer
    └── Everything else (Docker)

Pros:

Maximum performance (no hypervisor overhead)
One OS to patch
Simple mental model
You get to tell people "I run bare metal" at parties

Cons (for me):

No VM isolation — Home Assistant must run as a VM (Home Assistant OS), not a container. What about a Windows VM for that one tool? Or a test TrueNAS VM? Or a GPU-passthrough VM for AI experiments? (Yes, I know nested virtualization exists. No, I don’t want to debug it.)
No snapshots of the OS — Proxmox backs up the entire VM (disk + config). Bare metal = tar your /etc and hope. (Been there. Restored /etc from a tar once. The resulting Frankenstein config haunted me for weeks.)
Kernel updates = reboot everything — With Proxmox, VMs keep running during host kernel updates (mostly).
GPU passthrough to Docker — works but nvidia-container-toolkit + Docker runtime config is fiddlier than Proxmox’s "PCI Device → VM" checkbox.

Also, "bare metal" sounds cool until you’re the one holding the screwdriver at 2 AM.

Why Proxmox Won (The Actual Decision Matrix)

Criterion	Proxmox	TrueNAS SCALE	Unraid	OMV	Bare Metal
ZFS native	✅ Host-level	✅ Host-level	⚠️ Plugin	⚠️ Plugin	✅ Kernel module
VM + LXC	✅ Both	✅ VM only	✅ VM only	❌	❌
GPU passthrough	✅ Checkbox	✅ Config	✅ Config	⚠️ Manual	⚠️ Manual
Backup (VM-level)	✅ Built-in	⚠️ Manual	⚠️ Manual	❌	❌
HA / Clustering	✅ Native	⚠️ Limited	❌	❌	❌
Cost	Free	Free	$129+	Free	Free
Learning curve	Medium	Low	Medium	Low	Low
My use case fit	✅ Best	❌ ZFS-on-ZFS	❌ Proprietary	❌ ZFS plugin	❌ No VMs

The Architecture I Landed On

Proxmox Host (bare metal) — Infra Node
    ├── ZFS Pool: /tank (3×2 TB RAID-Z) ← STORAGE LAYER
    │       ├── /tank/data  → bind mount → Samba VM
    │       ├── /tank/media → NFS export → Smart Node (media stack)
    │       ├── /tank/services → bind mount → Docker VM (Portainer)
    │       └── /tank/temp → bind mount → Docker VM (downloads)
    │
    ├── VM: Samba + Webmin (Debian 12) ← NAS layer
    │       └── Mounts /tank/data, /tank/media via VirtIO-FS
    │
    ├── VM: Home Assistant (Debian 12) ← Automation
    │       └── Zigbee/Z-Wave USB passed through
    │
    └── VM: Docker/Portainer (Debian 12) ← App runtime
            ├── AdGuard, Docmost, Immich, n8n, Twingate connector, Cloudflare Tunnel (containers)
            └── Mounts /tank/services, /tank/temp via bind mount

Smart Node (bare metal Debian 12) — separate physical machine
    ├── Docker + Portainer
    │       ├── Media stack (*Arr, qBittorrent, Plex)
    │       ├── Ollama + local LLMs
    │       └── GPU transcoding (GTX 1060 NVENC/NVDEC)
    │
    └── NFS mount: /tank/media from Infra Node

Key insight: Proxmox host = storage layer. ZFS lives once, on the Infra Node host. VMs consume storage via bind mounts, NFS, or VirtIO-FS. No ZFS-on-ZFS. No double caching. Single source of truth.

The `mp0` Bind Mount Trap

Proxmox has mp0 (mount point 0) for bind-mounting host paths into VMs. Documentation says "works for QEMU VMs."

It doesn’t. mp0 only works for LXC containers (they share the host kernel). For QEMU VMs, the mount happens inside the guest — but the guest kernel doesn’t see the host path.

I wasted an evening on:

# Proxmox host
mp0: /tank/data,mp=/mnt/data

Inside Debian VM: mount | grep mnt/data → nothing. systemd fails. fstab fails. My search history from that night: "proxmox mp0 not working qemu", "proxmox bind mount vm virtiofs", "why does mp0 only work for lxc", "proxmox documentation lies".

Solution: VirtIO-FS for VMs, bind mounts only for LXC.

# Proxmox VM config (via GUI or /etc/pve/qemu-server/100.conf)
virtiofs0: source=/tank/data,target=data
virtiofs1: source=/tank/media,target=media

Inside VM:

# /etc/fstab
data  /mnt/data  virtiofs  defaults  0  0
media /mnt/media virtiofs  defaults  0  0

Works. But: VirtIO-FS requires QEMU 6.0+ and kernel 5.10+ — fine for Debian 12, not for older distros.

Moral of the story: If the documentation says "works for VMs" and it only works for containers, that’s not a feature — that’s a typo that cost you three hours.

The Honest Summary

Proxmox won because it was the only option that gave me:

Host-level ZFS (no double-caching)
Both VMs and LXCs
Native backup of entire VMs
Free, no license drama
GPU passthrough via checkbox

It didn’t win because it’s perfect. The ZFS management is CLI-first. The VM backup is slow for large disks. The clustering is LAN-only. The UI shows "No subscription" nag on login (which I now read as "congratulations, you’re not giving us money").

But for a homelab with mixed workloads (NAS + AI + media + automation + HA) on consumer hardware in a single location — it’s the least-wrong choice.

And honestly? The "No subscription" nag is the most honest thing about it. It’s the only software that tells you exactly what you’re not paying for every time you log in.

Category: Homelab Journey