Proxmox #2 — Build Your Own File Server (NAS) with TrueNAS and Proxmox

Dariusz Luber

2026-07-12T08:00:00.000Z

📺

Prefer video content?

For the best experience, use both — watch the video and read the article; together they give you the full picture

A disk array (NAS — Network Attached Storage) protects your data against a single drive failure — if one, two, or even three drives die (depending on the setup), you won't lose anything. That said, this is not a backup. Redundancy on a NAS won't save you from accidentally deleting files or from ransomware — a real backup has to live somewhere else entirely.

TL;DR

You install TrueNAS as a VM on Proxmox, but the actual data lives on drives passed through directly to the VM (Disk Passthrough) — never on a virtual .qcow2 disk.
Three pitfalls wreck most first attempts: a checked Pre-Enrolled keys box (Secure Boot blocks the boot), the default graphics card (frozen/black installer screen), and a missing serial parameter when passing through disks (TrueNAS won't create a pool without unique serial numbers).
Set RAM as a hard allocation and disable Ballooning — ZFS expects exclusive control over its RAM (the ARC cache), or you're risking a kernel panic.
Every drive in a ZFS pool must be the same size — a smaller drive caps every other drive down to its own capacity.
Once the pool exists, you don't share the whole disk — you create Datasets, SMB-only users, and grant them permissions (ACL).

1) TrueNAS SCALE or CORE?

TrueNAS SCALE (Debian-based, just like Proxmox) is now the better pick over the older CORE branch — it lets you scale a pool easily by adding single drives, without rebuilding the whole array or migrating data. CORE tends to be more rigid here.

At the heart of both versions is ZFS — a filesystem that natively guards data integrity, self-heals errors on the fly, and supports instant snapshots.

Golden rule: ZFS is designed to talk directly to the physical hardware. Don't put your data on virtual disks (.qcow2) — use Disk Passthrough instead.

2) Requirements and downloading the ISO

Minimum requirements for the TrueNAS VM:

RAM: 8 GB minimum — ZFS uses RAM as its ARC (Adaptive Replacement Cache), keeping the most frequently used data and metadata in memory so it can be read instantly instead of hitting the slower disk every time; the more RAM you give it, the bigger and more effective that cache gets.
CPU: 2 cores minimum, Host type.
System disk: ~32 GB, dedicated purely to the OS (your actual data lives on separate, passed-through drives).

The most convenient way to grab the ISO skips the usual "download to your PC, then upload to Proxmox" round-trip:

On the TrueNAS site, copy the link to the .iso you want (right-click → Copy link) instead of downloading it.
In Proxmox: Datacenter → your node → local → ISO Images → Download from URL, paste the link, and confirm.
Proxmox fetches the file straight to its storage — no manual upload needed.

Pay attention to the version: the TrueNAS download page shows which release is currently stable (labeled General) versus a newer one aimed at early adopters. For a home NAS that's going to hold real data, pick the stable one.

3) Creating the VM in Proxmox

Create VM → give it an ID and a name (e.g. TrueNAS), check Start at boot.
OS: point it at the TrueNAS ISO you downloaded, Type: Linux.
System: switch the BIOS from SeaBIOS to OVMF (UEFI) — required by TrueNAS for proper booting and for handling modern partition tables (Machine type will auto-switch to q35). Add an EFI disk.

Critical: when adding the EFI disk, uncheck Pre-Enrolled keys. Checking it enables Secure Boot and preloads trusted certificates (Microsoft's, among others) — the TrueNAS installer won't recognize them and will refuse to boot (Failed to Load). Leave it unchecked — TrueNAS will trust the disk and write its own GRUB bootloader there.
SCSI controller: VirtIO SCSI single.
Graphic card: switch it to VirtIO-GPU — the default card is often incompatible and can freeze or blank out the TrueNAS installer/console screen.
Disks: ~32 GB system disk.
- Cache: No cache (avoids double buffering across host and guest; TrueNAS already manages its own writes) or, optionally, Write back (a modest write-speed boost at the cost of safety during a sudden power loss).
- Check Discard if Proxmox runs on SSD/NVMe storage — it enables TRIM, extending the media's lifespan.
CPU: 2 cores minimum, Type: Host — gives direct access to the physical CPU's instruction set, which meaningfully speeds up array operations and disk encryption (an emulated CPU type would be noticeably slower here).

The cost of picking Host: live migration (HA) between cluster nodes gets harder. In this setup that's a non-issue — since you're already passing through physical disks (Disk Passthrough), the VM couldn't migrate to another host without the same physical drives anyway. You achieve NAS reliability (HA) differently: a second physical TrueNAS box on another host plus native ZFS replication.
Memory: uncheck Ballooning, enter a hard value, e.g. 8192 MB (a rough rule of thumb is about 1 GB of RAM per 1 TB of pool space — if you have more RAM available, give it more, it'll only improve caching).

Why does this matter? ZFS keeps this allocated memory under its own exclusive control as the ARC (Adaptive Replacement Cache) — the caching mechanism described in section 2, which serves reads of frequently used data and metadata straight from RAM instead of the slower disk. With Ballooning enabled, Proxmox dynamically takes and returns RAM on the fly — for ZFS that's a disaster: performance drops, and in the worst case, a kernel panic and data corruption.
Network: leave it on VirtIO (paravirtualized).

Once you close the wizard, don't start the VM yet — Disk Passthrough comes first.

4) Disk Passthrough — passing through physical drives

In the Proxmox node's console (Shell):

ls -l /dev/disk/by-id/ | grep -v "-part"

The | grep -v "-part" part filters out partitions, leaving a clean list of devices. Look for the drives meant to hold data (usually prefixed ata-... or nvme-...) and copy their full paths — the serial number you'll plug into the qm set command below is usually just the last segment of that same name, after the final hyphen (e.g., in ata-WDC_WD40EFRX-...-WD-XXXXXXXXX, that's WD-XXXXXXXXX).

Attach them to the VM (replace 102 with your machine's ID):

qm set 102 -scsi1 /dev/disk/by-id/ata-drive-name-1,serial=SERIAL_NUMBER_1
qm set 102 -scsi2 /dev/disk/by-id/ata-drive-name-2,serial=SERIAL_NUMBER_2

The serial parameter is mandatory. If the by-id name doesn't have a readable serial in it, check the drive's physical label instead. Without this parameter, TrueNAS only sees generic "QEMU disks" — and in newer versions, missing unique serial numbers completely blocks pool creation, because TrueNAS can't reliably tell the drives apart. On top of that, when a drive fails, the serial number in the UI immediately tells you which physical drive to pull.

If your storage drives sit behind a dedicated HBA controller, an alternative is PCIe Passthrough of the whole card — TrueNAS then takes over every drive attached to it and reads their serial numbers natively.

You'll see the attached drives right away under the VM's Hardware tab.

5) Common errors on first boot

Two problems show up often enough that it's worth knowing about them ahead of time:

Failed to Load / the installer won't start — this is Secure Boot from the checked Pre-Enrolled keys box in section 3. To fix it: stop the VM (Stop, not Restart), remove the EFI disk, add it back with Pre-Enrolled keys unchecked, and boot again.
Frozen or black installer screen — an incompatible graphics card. Stop the VM, change Graphic card to VirtIO-GPU under Hardware, and boot again.

If TrueNAS refuses to create a pool after you passed through disks without the serial parameter: stop the VM, detach (Detach) and remove the drives under Hardware, redo the qm set commands with ,serial=... appended, and start the VM again.

6) Installing TrueNAS

Start → Console.
Choose Install/Upgrade.
For the target disk, pick the small virtual system drive (32 GB, usually sda/vda) — do not select your passed-through data drives here.
Set a strong password for the truenas_admin account.
Confirm booting in EFI/UEFI mode and wait for the install to finish.
The system will ask for a reboot — under Hardware → CD/DVD Drive, select Do not use any media, remove the mounted ISO, and restart the VM.

After the reboot, the console will show the DHCP-assigned IP address (e.g. http://192.168.1.50) — open it in a browser and log in as truenas_admin.

Anyone with access to the VM console in Proxmox also has direct access to the TrueNAS console, no extra login required — keep an eye on who has access to Proxmox itself.

7) Creating the pool and choosing a VDEV topology

Storage → Create Pool. The interface will auto-detect the passed-through drives along with their serial numbers. Your options include:

Stripe — drives simply add up their capacity, with zero redundancy. One drive fails, you lose everything in the pool. Not recommended for anything you actually want to keep.
Mirror (RAID 1) — a full copy across at least 2 drives. A single drive failure costs you nothing.
RAID-Z1 (RAID 5) — the capacity of one drive goes toward parity data, which ZFS uses to rebuild things after a failure. Minimum 3 drives, survives one drive dying.
RAID-Z2 (RAID 6) — same idea, but you "spend" two drives' worth of capacity on parity. Minimum 4 drives, survives two drives dying at once.

The drive-size trap: every drive in a pool must have the same capacity. Mix in, say, two 4 TB drives with one 2 TB drive? ZFS will cap all of them down to 2 TB — the extra space is simply wasted until you swap the smallest drive for a bigger one.

Advertised vs. actual TB: manufacturers often count 1 TB as 1000 GB (decimal), while ZFS reports in binary units (TiB) — a "4 TB" drive will show up in the pool as roughly 3.64 TiB. That's expected, not a bug.

With enough drives, you'll also see options for a Spare drive (sits idle and automatically steps in when a drive in the pool fails — handy if you can't get physical access to the server right away), plus separate drives (ideally SSD/NVMe) dedicated to Cache/L2ARC and metadata, which speed up reads and writes.

Turn on Encryption if the pool will hold sensitive data — without the key, nobody can read the data even with physical access to the drives. Confirm with Create Pool (the drives will be wiped clean — make sure you selected the right ones).

8) Datasets, SMB users, and permissions (ACL)

The pool itself is just the foundation — you never share the raw disk directly. Instead, you create Datasets: think of them as shared folders, each of which can have its own space limits, snapshots, compression, and permissions. (The Add Zvol option next to Dataset is something different — a block-level virtual volume for things like iSCSI; skip it for now.)

Step 1 — an SMB-only user. Don't log into your shares with the truenas_admin account. Under Credentials → Users → Add, create an account (e.g. darek), set a password, and — critically — check Samba Authentication; without that flag the user can't authenticate against a network share. If the account only needs to exist for SMB, you can skip creating a home directory and leave out shell/SSH access.

Step 2 — the Dataset. Storage → your pool → Add Dataset. Give it a name (e.g. Home) and set Share Type to SMB — TrueNAS will then pick the parameters best suited for Windows clients (including turning off case sensitivity). Under Advanced Options, it's also worth disabling Enable Atime if you're on spinning HDDs — otherwise every file read logs an access timestamp, generating unnecessary head movement.

Step 3 — the SMB share and ACL. Shares → Windows (SMB) Shares → Add, point it at the Dataset. On first setup, the system will prompt you to configure ACL permissions. Common scenarios:

A private resource: use the Restricted template, remove the default groups, and leave just the owner with Full Control. Nobody else on the network gets in.
A shared resource: use the Open template, add the built-in builtin_users group (every new local user lands here by default) with Modify permissions.
A read-only resource (e.g. a photo archive): owner gets Full Control, the builtin_users group gets Read only — nobody accidentally wipes the collection.
A resource for select people: use Restricted, owner keeps Full Control, then Add Item → pick a specific user (e.g. ania) and grant Read or Modify. The rest of the network still has no access.

Nothing stops you from repeating steps 2–3 a few times to have separate Datasets per household member or data category (Home, Kids, Videos) — each with its own permissions.

Summary and what's next

A virtual TrueNAS with correct Disk Passthrough and a hard, non-ballooned memory allocation holds up just as well as a physical NAS, both in stability and in performance.

And this is only the starting point. TrueNAS SCALE comes with a built-in app catalog, so you can spin up things like Immich on the same server — a self-hosted equivalent of Google Photos, complete with AI face recognition and tagging, but running entirely on your own drives. Instead of uploading phone photos to Google Photos or files to Google Drive, you keep them at home — and it's you, not some third-party company, who decides who gets access. That's the real power of running your own homelab.

In the next part: hardening TrueNAS — managing permissions through groups, automated backups (Cloud Sync), ZFS snapshots as ransomware protection, and secure access to your homelab resources from outside your home network via VPN (WireGuard).