TrueNAS Scale on Proxmox: Running Real Storage as a VM
The two install paths, why HBA passthrough beats passing through individual disks, and the ZFS-on-ZFS mistake worth avoiding from the start.
Pairing TrueNAS Scale with an existing Proxmox cluster is a natural next step once you're already comfortable running VMs: instead of a dedicated NAS box sitting idle most of the day, storage becomes one more guest on hardware you're already running. It's also the one guide on this site where getting the setup wrong doesn't just mean a broken service. It means degraded protection for the actual data you're trying to keep safe, so the passthrough decision below gets more attention than usual.
Why a VM (and Not an LXC)
Unlike some of the other apps covered on this site, TrueNAS Scale as an LXC container isn't a "works but not recommended" situation, it just isn't supported. TrueNAS needs to load ZFS with its own kernel and see physical storage hardware directly; an LXC shares the Proxmox host's kernel instead, which breaks both of those assumptions. It has to be a full VM, the same hard requirement Home Assistant OS has, for a similar reason.
The upside of running it as a VM at all, instead of on a dedicated physical NAS box: one less piece of standalone hardware, and the VM itself gets Proxmox-level snapshots for its boot/config disk, on top of whatever redundancy TrueNAS's own ZFS pool is providing for the actual data.
Getting It Running
Both real paths end up running the same installer against the same official image; the difference is how much of the VM shell gets built for you first.
- Community script: run
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/truenas-vm.sh)"on the Proxmox shell. It downloads the current stable TrueNAS ISO, builds a VM around it correctly (q35 machine type, OVMF/UEFI firmware, VirtIO SCSI controller, 2 vCPUs, 8GB RAM, a 16GB boot disk), and optionally lets you pick physical disks to pass through by their serial number right there in the script. It still boots to the graphical TrueNAS installer, one click-through, not a fully unattended install. - Manual ISO install: download the current TrueNAS ISO from the official TrueNAS downloads page, create the VM by hand with the same q35/OVMF/VirtIO SCSI settings, and attach it as the VM's CD-ROM to boot the installer. This is the path if you're setting up full HBA passthrough (see below) and want to add the controller before the first boot, or you'd rather not run a third-party script against your hypervisor.
Either way, keep the VM's own boot/config disk small (16GB is plenty) and separate from the actual storage pool disks. The boot disk can live on normal Proxmox storage, but the storage pool itself needs real physical disks passed through, which is the whole next section.
The Passthrough Decision That Actually Matters
This is the one choice on this page worth slowing down for, since it affects how much you can trust TrueNAS's own disk health reporting later.
- HBA/controller passthrough (best practice): pass an entire SATA or SAS controller through to the VM as a PCI device (Proxmox's Hardware → Add → PCI Device, selected as a Raw Device with All Functions checked), so TrueNAS talks to every disk on that controller directly. This needs the controller to sit in its own IOMMU group and generally means a separate HBA card beyond whatever's built into your motherboard, since the onboard SATA controller is often shared with the boot drive. The payoff is accurate S.M.A.R.T. data, proper disk spin-down, and disks that show up in TrueNAS exactly the way they would on bare metal.
- Individual disk passthrough by ID (a reasonable middle ground): attach specific physical disks to the VM by their
/dev/disk/by-id/path (what the community script's disk-passthrough option does under the hood) rather than a raw/dev/sdX, which can silently reassign after a reboot. This is the practical option on a single mini PC or NAS box without a spare PCIe slot for an HBA, and it's a fine choice for a home setup, just with less direct disk-health visibility than full controller passthrough.
What to avoid either way: putting TrueNAS's storage pool on a Proxmox ZFS-backed virtual disk. That's ZFS running on top of ZFS, double checksumming and double copy-on-write for no real benefit, and it's a surprisingly easy mistake to make if you just click through the default VM disk options without thinking about where the actual bytes end up.
First Boot and Creating a Pool
After the installer finishes and reboots, the VM's console shows the web UI's IP address directly. Log in, set a strong admin password if the installer didn't already prompt for one, and head to Storage → Create Pool. This is where the passthrough decision above actually pays off or doesn't: only disks TrueNAS can see directly (via HBA or by-ID passthrough) show up as pool candidates, so if a drive is missing here, it's almost always a passthrough problem to go fix in Proxmox, not a TrueNAS one.
Pick a RAIDZ level based on how many drives you have and how much you can afford to lose to parity (mirrors for 2 drives, RAIDZ1 for 3-5 with one drive of redundancy, RAIDZ2 for larger arrays where a second drive failure during a rebuild is a real risk). Once the pool exists, shares (SMB, NFS) and apps both live under their own sections in the sidebar.
A Few Things That Trip People Up
Turn off RAM ballooning for the VM (set both Minimum and Maximum memory to the same value in the VM's Hardware tab). TrueNAS assumes it fully owns whatever RAM it's given for ZFS's ARC cache, and a Proxmox balloon driver reclaiming memory out from under it has caused real crashes and startup failures for people who left it on.
ECC RAM is not required, despite what older forum threads insist. It's nice to have for datacenter-grade bit-flip protection, but for a home setup with normal backups, non-ECC RAM on a mini PC or consumer motherboard is a completely reasonable choice, and it's what most people running this setup actually have.
A Few Things I'd Get Right From the Start
1. Never put the storage pool on a ZFS-backed virtual disk
Covered above, but it's the single most common architecture mistake here. Physical disks, passed through, or don't bother running TrueNAS as a VM at all.
2. Disable RAM ballooning before the first boot
Set Minimum RAM equal to Maximum RAM in the VM's hardware settings. This is a two-minute fix that prevents a class of crash that's confusing to diagnose after the fact.
3. Give it more RAM than the 8GB minimum
16GB is a realistic floor for actual use once ZFS's ARC cache and any apps are competing for the same pool of memory.
4. Keep the boot/config disk separate from pool disks
A small virtual disk on normal Proxmox storage for the OS, physical disks passed through for the actual pool. Don't mix the two roles onto the same disk.
5. Set the VM to start on boot, same as any other always-on service
If the host reboots unattended, you want your NAS back online without having to remember to start it by hand, same convention as every other guide on this site.
Related Resources
Official TrueNAS Download
The ISO this guide's manual method installs from.
Proxmox VE Helper Scripts: TrueNAS
The community script this guide's easy path runs.
NAS Enclosure Tracker
Live pricing if you'd rather buy a pre-built TrueNAS box instead.
Proxmox Updates
What's new in Proxmox VE, kept current with a live feed.
Home Assistant on Proxmox
Another app that has to be a full VM, and why.
Data Hoarding
My actual data collection, archival, and storage philosophy.
Frequently Asked Questions
Is it still called TrueNAS Scale, or just TrueNAS now?
Officially, iXsystems folded the SCALE and CORE branding into one product line and calls the current release just "TrueNAS," with the Linux-based codebase (what used to be SCALE specifically) as the only actively developed branch going forward. Almost everyone, including most current guides and forum threads, still says "TrueNAS Scale" out of habit, so this guide uses both, but if you're downloading the ISO today, the button just says TrueNAS.
Should I use the community script or download the ISO myself?
The community script builds the VM correctly around the ISO for you (q35, OVMF/UEFI, VirtIO SCSI, 8GB RAM, and an optional pass of your existing disks by serial number), but it still boots into the graphical installer rather than a one-command finished VM like the Home Assistant script does, you still click through the TrueNAS installer once. A manual ISO download is worth it if you want to build the VM by hand around a specific HBA passthrough setup, since the script's disk-passthrough option is the simpler by-ID method, not full controller passthrough.
Do I need a dedicated HBA card, or can I just pass through individual disks?
You don't strictly need one, but the community consensus is clear about which is better. Passing through a whole HBA/SAS controller gives TrueNAS direct hardware access to every disk on it, accurate S.M.A.R.T. data, proper disk sleep, and no Proxmox layer in between. Passing through individual disks by their /dev/disk/by-id serial (what the community script offers) works and is a reasonable starting point on a single mini PC with only a couple of drives, but you lose some of that direct disk health visibility. Either beats passing disks through by raw /dev/sdX path, which can silently reassign after a reboot.
Why not just put TrueNAS's storage on a Proxmox ZFS-backed virtual disk?
That's ZFS-on-ZFS: TrueNAS's own ZFS pool sitting on top of a virtual disk that Proxmox is already serving from its own ZFS pool. Both layers do checksumming, both do copy-on-write, and the result is write amplification and confusing failure behavior for no real benefit. Give TrueNAS physical disks (via HBA or by-ID passthrough) for its actual storage pool, and keep the VM's own boot disk on whatever Proxmox storage you'd use for any other VM.
How much RAM does TrueNAS Scale actually need?
TrueNAS's official minimum is 8GB, and the community script provisions exactly that by default, but 8GB is a bare-metal-install floor, not a comfortable target. ZFS wants RAM for its ARC read cache, and every app or VM you run inside TrueNAS Scale on top of that eats into the same pool. 16GB is a realistic minimum for a NAS you'll actually use day to day; 32GB is where most home users stop noticing RAM as a constraint at all.
Can TrueNAS Scale run in an LXC container instead of a VM?
No, and this one isn't optional the way it sometimes is for other apps. TrueNAS Scale needs its own kernel to load ZFS the way it expects and to see physical storage hardware directly, neither of which an LXC's shared host kernel can provide safely. It has to be a full VM, with either an HBA or individual disks passed through to it, the same requirement Home Assistant OS has and for a similar reason.