Build a ZFS NAS with TrueNAS

What you'll build and why

TrueNAS turns a machine and its drives into real network-attached storage, with ZFS doing the actual data-integrity work underneath: checksums on every block (catching corruption a plain filesystem wouldn't notice), snapshots that cost almost nothing until data actually changes, and pool layouts that survive a drive failure without losing anything. This is meaningfully more robust than "a shared folder on a spare drive," and this guide builds it properly from pool layout up.

Don't build this if: you have one or two drives and no plan to add redundancy -- ZFS's real value is in the redundancy and integrity checking a multi-drive pool provides; a single-drive setup doesn't get much of that. You also don't need a dedicated NAS if your storage needs are already served by what you're doing elsewhere in this section (e.g. Proxmox's own local ZFS storage) and you don't have a specific reason to separate storage from compute.

How it works

  Physical drives
│
▼
vdev (a group of drives with a specific redundancy
scheme -- mirror, RAIDZ1, RAIDZ2)
│
▼
Pool (one or more vdevs combined -- this is the
storage TrueNAS actually manages and reports
capacity for)
│
▼
Datasets (logical divisions within a pool -- each
can have its own permissions, quotas, and
snapshot schedule, like folders with real
storage-level properties)

A vdev is the actual redundancy unit -- losing more drives than that vdev's scheme tolerates loses the whole pool, not just that vdev, which is why vdev layout is the single most consequential decision in this guide.

Before you start

Decision: which pool layout for your drive count?

For anything beyond a small handful of drives, RAIDZ2 is the generally recommended default in current ZFS community guidance -- rebuild times on large modern drives are long enough that a second failure during rebuild is a real, not theoretical, risk RAIDZ1 doesn't protect against.

Steps

Step 1: Install TrueNAS

Flash the installer to a USB drive, boot from it, and follow the installer: select the target boot device (a dedicated drive, not one of your storage drives), set the admin password, complete the install and reboot.

Editor's note on this step's verification: TrueNAS's installer flow is based on well-established convention consistent with every recent TrueNAS release family, not individually re-confirmed against a specific fetched installer walkthrough this session. Check truenas.com/docs directly if your installed version's screens differ meaningfully.

Step 2: Create your pool

In the web UI: Storage → Create Pool, select your data drives, and choose the vdev layout from your Before you start decision. Double-check drive selection carefully -- this step formats the selected drives.

Step 3: Create datasets

Storage → [your pool] → Add Dataset for each logical division you want (e.g. separate datasets for media, backups, documents) -- each dataset can have its own permissions and snapshot schedule independently.

Step 4: Set up a snapshot schedule

Data Protection → Periodic Snapshot Tasks → Add, per dataset: how often, and how long to retain. Snapshots are cheap (they only consume space for data that's changed since the snapshot was taken) -- reasonably frequent snapshots with a sensible retention window is the common pattern.

Step 5: Set up a scrub schedule

Data Protection → Scrub Tasks -- a scrub reads every block in the pool and verifies its checksum, catching silent corruption before it becomes a real problem. Monthly is a common, reasonable default.

Step 6: Share storage to the network

Shares, add an SMB share (for Windows/general use) or NFS share (for Linux/Proxmox), pointed at the dataset(s) you want network-accessible.

Verify it works

• Storage → [pool] shows the expected capacity and vdev layout
• A network client can connect to and read/write a share
• A manual snapshot (Data Protection → Snapshots → Add) succeeds, and you can browse its contents (each dataset's .zfs/snapshot/ directory, or via the UI) without it affecting the live data
• A manual scrub run (Data Protection → Scrub Tasks → Run Now) completes without reporting checksum errors on a healthy pool
• Failure test: if you have a spare/test drive to sacrifice, or are comfortable simulating it in a test pool first -- pull one drive from a redundant pool (mirror or RAIDZ) while it's running. Confirm the pool stays online in a degraded state rather than going offline, and that resilvering (rebuilding onto a replacement) completes successfully once you reinsert or replace the drive

Secure it

• What's exposed: the TrueNAS web UI and any configured shares -- scope both to your LAN, not the internet. SMB/NFS shares in particular should never be directly internet-facing.
• Default credentials: the admin password you set during install (Step 1) is the only one -- no separate default to worry about.
• Least privilege: scope SMB/NFS share permissions to the specific users/networks that need them, rather than open access, especially for datasets holding anything sensitive.
• The failure that hurts most: treating snapshots as your backup strategy. A snapshot lives on the same pool it's protecting -- it defends against accidental deletion or ransomware-style overwrite, but not against the whole pool/machine being lost. See the 3-2-1 backups guide for what actually protects against that; this NAS is often the source of data that guide backs up elsewhere, not a replacement for doing so.

Back it up and maintain it

What matters: this NAS's own data needs backing up too -- see the 3-2-1 backups guide (restic can back up from a TrueNAS dataset like any other filesystem; TrueNAS also supports native ZFS replication to a second TrueNAS system as an alternative offsite-adjacent option).

Update cadence: TrueNAS ships regular releases -- update deliberately, reading release notes first, similar to any infrastructure component where a bad update has real consequences.

What to monitor: SMART data per drive (Storage → Disks, or configured SMART tests under Data Protection) for early failure warning signs; pool capacity trending toward full (ZFS performance degrades as a pool fills, well before it's literally full).

Troubleshooting

Logs: System → Advanced Settings → Logs, or the underlying system logs for deeper issues.

Undo

Storage → [pool] → Export/Disconnect to remove a pool from TrueNAS (data remains on the drives unless you also choose to destroy the data during export -- read the confirmation carefully). Reformat or repurpose the drives once you've confirmed you no longer need the data.

Go further

• Real 3-2-1 Backups with restic and Proxmox Backup Server -- back up this NAS's own data offsite, since snapshots alone (Secure it) aren't a full backup strategy
• Set up ZFS replication to a second TrueNAS system if you want a real offsite/secondary copy at the block level, not just file-level backup
• Explore TrueNAS's app/container support (Community Edition now runs Docker apps directly, per its current documentation) if you want this same box to also run lightweight self-hosted services

Resources

Official documentation:

• TrueNAS Community Edition -- current release information
• TrueNAS documentation hub -- ZFS primer and reference material

Source and releases:

• TrueNAS on GitHub

Community:

• TrueNAS Community Forums
• r/truenas

Related DaemonPress projects:

• Real 3-2-1 Backups with restic and Proxmox Backup Server
• Managing a Homelab with Docker Compose, Portainer, and Watchtower

Last verified: 2026-09-21, checked against TrueNAS's current documentation structure and release naming.