Work Out How Much Storage You Need
It's easy to buy far more capacity than you'll use. Before choosing drives, measure what you actually have: run du -sh on the folders you plan to move, or check the used space on your current drives and cloud accounts. Group it into media, photos, documents and machine backups, estimate how fast each grows, and then add headroom for growth and for the free space ZFS needs to perform well.
Remember that redundancy costs capacity. A two-drive mirror gives you the space of one drive; a RAIDZ1 vdev gives you roughly the space of all drives but one, and RAIDZ2 all but two, minus some ZFS overhead. The pool creation docs link to a ZFS capacity calculator for comparing layouts.
Why TrueNAS?
ZFS stores a checksum for every block. When it reads a block whose checksum doesn't match, it knows the data is damaged and, if the pool has redundancy, repairs it from a good copy. Many simpler NAS setups have no way to notice that kind of silent corruption until a file won't open.
TrueNAS packages ZFS with a web interface for pools, shares, snapshots, replication and alerts, so you don't have to manage ZFS from the command line.
Which TrueNAS to Install
- TrueNAS Community Edition - the free, Linux-based version (formerly called SCALE). Since the 25.04 "Fangtooth" release it carries this name, as announced in Meet TrueNAS Community Edition. Choose this for a new install.
- TrueNAS CORE 13.x - the older FreeBSD-based version. It has moved to a maintenance phase, and TrueNAS documents a migration path from CORE to Community Edition.
When this page was updated, the TrueNAS Software Status page recommended 25.10.7 ("Goldeye") for general and mission-critical users, and offered 27.0.0-RC.1 to early adopters. TrueNAS 27 is the release previously announced as 26; it was renamed at RC.1, and a release candidate isn't meant for data you depend on. Check that page before you download; the menu paths below follow the 25.10 documentation.
Drives Are the Running Cost
The software is free. The ongoing cost is drives, which wear out and fail. Plan for replacing them, and buy CMR drives: the TrueNAS hardware guide describes SMR drives as a poor fit for ZFS because of slow writes and unreliable resilvers. When a disk fails, its replacement must be at least as large.
A failed disk also leaves the pool degraded while ZFS rebuilds ("resilvers") onto the replacement. In a RAIDZ1 vdev or a two-way mirror, you have no redundancy left during that window, and a second failure in the same vdev loses the pool. Resilvering large drives takes a long time, which is why RAIDZ2 is often preferred for bigger drives and wider vdevs, at the cost of one more drive's capacity. Redundancy isn't a backup either; see replication below.
Before trusting new or used drives with data, the hardware guide suggests a burn-in: a long SMART self-test (smartctl -t long /dev/sdX), then checking smartctl -a for pending or reallocated sectors and CRC errors, and for power-on hours that don't match what the seller claimed.
Hardware Requirements
From the TrueNAS hardware guide and installation docs:
- CPU: a 64-bit Intel or AMD (x86_64) processor; two cores is the listed minimum
- RAM: 8 GB for basic use with up to eight drives, plus about 1 GB for each additional drive, and more for apps, VMs or many clients
- Boot device: a separate small SSD (the install guide asks for at least 20 GB); USB sticks are discouraged because TrueNAS writes to the boot pool regularly
- Data drives: at least two identically sized drives for a redundant pool
- Controller: onboard SATA or an HBA in IT/passthrough mode. Don't use a hardware RAID card's RAID function; ZFS needs direct access to the disks
The hardware guide also has a section on ECC memory. For a machine whose job is storing data you care about, ECC is a sensible choice when your platform supports it, because it detects and corrects memory errors before they can be written to disk. TrueNAS runs without it.
Installation
- Download the Community Edition ISO from truenas.com and compare its SHA256 checksum with the published
.sha256file (sha256sumon Linux). - Write it to a USB stick: Rufus or Ventoy on Windows, or
ddon Linux, as described in the installation docs. - Boot the server from the USB stick.
- Select the boot SSD as the installation target. Double-check it: the installer erases the disk you pick, and it should not be one of your data drives.
- When asked for the authentication method, choose Administrative user (truenas_admin) and set its password. The root password stays disabled, which is the recommended setup.
- Reboot and remove the USB stick.
After boot, the console shows the web interface address. TrueNAS uses DHCP by default and also answers on truenas.local where mDNS works.
Initial Web UI Setup
Log in as truenas_admin with the password you set. The first login docs recommend creating your own administrator account under Credentials → Users and then disabling the default account's password.
Network Configuration
Go to Network and click Settings on the Global Configuration widget.
- Set the hostname and domain
- Configure DNS servers and the default gateway
- Give the NAS a fixed address, either with a DHCP reservation on your router or a static IP on its interface
If you're planning VLANs or a separate storage network, the Networking Fundamentals guide explains subnets and gateways.
Creating a Storage Pool
This is the decision that's hardest to change later. Go to Storage and click Create Pool to open the pool creation wizard. The pool name can't be changed after creation.
VDEV Layouts
- Stripe: no redundancy; losing one disk loses everything. Not for data you care about.
- Mirror: every disk holds a full copy; capacity of one disk per mirror vdev
- RAIDZ1: one disk's worth of parity; survives one failed disk per vdev
- RAIDZ2: two disks of parity; survives two failures per vdev
- RAIDZ3: three disks of parity
- dRAID: meant for very large arrays; TrueNAS recommends RAIDZ when a vdev would have fewer than 10 data disks
For home use, a mirror is the simple choice with two drives. With three or more, RAIDZ1 gives the most space, while RAIDZ2 is the safer choice as drives get larger and the resilver window gets longer. The docs also advise against encrypting the whole pool: create an unencrypted pool and encrypt individual datasets if you need encryption, so a lost key doesn't lock the entire pool.
Creating Datasets
Datasets are like folders with their own settings: compression, quotas, permissions and snapshot schedules. Create them instead of putting everything in the pool's root dataset; the TrueNAS docs specifically warn against sharing the root dataset.
Go to Datasets, select the pool's root dataset, then click Add Dataset.
A typical split:
- Media
- Documents
- Backups
- App or VM storage
Separate datasets let you snapshot documents every hour but media once a day, set quotas, and choose the dataset preset that matches the share type. Leaving compression on is usually worthwhile; it costs little CPU and doesn't help much only for data that's already compressed, such as video and archives.
Setting Up Shares
SMB (Windows/Mac)
Create a local user for each person under Credentials → Users first, then go to Shares and click Add on the SMB widget.
- Select the dataset path
- Choose the share purpose (the default suits most file shares)
- Set permissions on the dataset so the right users can read and write
Connect from Windows: \\TRUENAS-IP\sharename; from macOS: smb://TRUENAS-IP/sharename
NFS (Linux)
Go to Shares and click Add on the NFS widget. NFS is the usual choice for Linux clients and hypervisors; limit the share to the networks or hosts that should mount it.
Mount on Linux:
sudo mount -t nfs truenas-ip:/mnt/pool/dataset /mnt/local
Proxmox can use the same NFS share for VM disks and backups (see the Proxmox VE Setup Guide), and Nextcloud can keep its data on it (see Nextcloud Self-Hosted Cloud).
Snapshots
ZFS snapshots are instant and use almost no space until data changes. Snapshots protect against deleted or overwritten files and against ransomware on client machines, but they live on the same pool, so they don't protect against losing the pool.
Go to Data Protection → Periodic Snapshot Tasks and click Add, as described in the snapshot task docs.
- Select the dataset
- Set the schedule (hourly, daily, weekly or custom)
- Set the lifetime (how long to keep each snapshot)
To restore, open Datasets, select the dataset and click Manage Snapshots in the Data Protection widget (or Data Protection → Periodic Snapshot Tasks → Snapshots), then expand the snapshot row. Clone it to a new dataset when you only need a few files back, and roll back only when you want to discard everything written since the snapshot. The snapshot docs warn that a rollback makes configured replication tasks fail.
Replication (Offsite Backup)
Replication sends snapshots to another pool, either on the same system or on a second TrueNAS or ZFS machine over SSH. A box at a relative's or friend's home is a common off-site target.
Go to Data Protection → Replication Tasks and add a task:
- Source: your dataset
- Destination: a dataset on the other system, over an SSH connection
- Schedule: daily, or tied to a periodic snapshot task
This is what gets you to a proper 3-2-1 backup: several copies, on different devices, with one off-site. Without an off-site copy, a fire, theft or power surge can take out the NAS and every drive in it. The Complete Self-Hosting Guide covers backup planning for the rest of a home server.
Alerts
Set up notifications so a failing drive gets your attention without you checking the dashboard. In the top toolbar, open the Alerts icon, then the settings icon:
- Email configures how TrueNAS sends mail
- Alert Settings sets which alerts are sent and how
Send yourself a test message to confirm it works, and make sure disk, pool and scrub alerts reach you.
Regular Scrubs
A scrub reads every block in the pool and verifies its checksum, repairing what it can from redundancy. It catches silent corruption and failing drives before you need the data.
Check under Data Protection → Scrub Tasks that each pool has a scheduled scrub. Monthly is a common interval. Scrubs add disk load while they run, so schedule them for a quiet time of day.
Apps
Community Edition runs apps as Docker containers. Go to Apps, click Discover Apps, choose an app and click Install to open its installation wizard, as described in the TrueNAS Apps documentation. For software that isn't in the catalog, Custom App on the same screen accepts a Docker Compose file.
Commonly installed apps include media servers such as Jellyfin, Syncthing for file sync, and Nextcloud. Keep app data in its own dataset so it can be snapshotted and replicated like everything else.
Back Up the System Configuration
Snapshots and replication protect your data, but not the settings that describe it: users, shares, tasks, network and storage configuration. If the boot SSD dies, a fresh install plus a saved configuration file gets those back. The system configuration docs describe the steps:
- Go to System → Advanced Settings, click Manage Configuration and select Download File.
- Leave Export Password Secret Seed selected and click Save.
Without the secret seed, a restored configuration loses its encrypted fields: SMB access for local users is disabled until each password is set again, and cloud credentials, SSH connections and the replication tasks that use them are deleted. Because the file with the seed can unlock those secrets, store it somewhere private and off the NAS. Download a new copy after every significant change.
If you use encrypted datasets, keep their key files or passphrases separately as well. TrueNAS never writes passphrases into the configuration file, and without them the data can't be unlocked.
Best Practices
- Use a two-drive mirror for two drives. For three or more drives, use RAIDZ1 or RAIDZ2, preferring RAIDZ2 for large drives, and check usable capacity in the pool wizard before creating the pool. RAIDZ2 needs at least four drives to leave meaningful space after two drives of parity.
- Use ECC memory if your platform supports it
- Schedule scrubs, and make sure alert emails actually arrive
- Leave free space in the pool; ZFS slows down as a pool gets close to full, so expand before it does
- Watch SMART data and replace drives that start reporting reallocated or pending sectors
- Test your restores. Pull a random file from an old snapshot and from the replicated copy now and then. A backup you've never restored from is untested.
Troubleshooting
- Can't reach the web interface. Use the address shown on the console, disable any browser proxy, and check that you can ping the NAS from the same network. The first login docs list these checks.
- Forgot the admin password. Connect a keyboard and monitor and use the Console Setup menu to reset it.
- Pool shows as degraded. A disk has failed or dropped out. Identify it by serial number before pulling anything, replace it with a disk of at least the same size, and let the resilver finish before doing other heavy work on the pool.
- SMB share asks for credentials or denies access. Log in with a TrueNAS local user, not the Windows account, and check that the dataset's permissions grant that user access.
- NFS mount is refused or files are read-only. Check that the client's network or address is allowed on the share, and that user and group IDs on the client match the dataset's owner.
TrueNAS rewards a bit of planning up front: choose the pool layout carefully, split data into datasets, and set up snapshots, replication and alerts before you fill the pool. After that it mostly runs itself, as long as you act on its alerts.



