A nine-year-old gaming PC isn’t supposed to become a personal cloud. The hardware is underpowered by modern server standards, the drives are aging, and you’re fighting against software never designed with this use case in mind. But with TrueNAS Scale and ZFS, the gap between “old box under the desk” and “enterprise-grade file server” is smaller than you’d expect.
This isn’t about clicking through the TrueNAS GUI. That’s fine for getting started, but it hides everything worth understanding: the ZFS commands executing underneath, the caching logic that makes old spinning disks feel fast, and the specific RAID mistakes that will destroy your data on aging hardware. By the end, you’ll have a mirrored storage pool, an isolated dataset with proper permissions, and an SMB share your Windows and Mac clients can actually use without permission errors.
Hardware and Firmware Prerequisites
TrueNAS Scale is built on Debian Linux and relies heavily on system RAM for caching — the more you have, the better the ARC (Adaptive Replacement Cache) performs. Beyond RAM, the critical requirement is a dedicated boot drive: a real SSD, not a USB thumb drive. TrueNAS writes OS logs constantly, and USB flash drives fail quickly under that kind of write amplification.
You need at least two identically sized HDDs for the data pool, a gigabit wired Ethernet connection (Wi-Fi is too inconsistent for a file server), and comfort with basic Linux permissions and networking concepts — specifically the difference between POSIX ACLs and NFSv4 ACLs, which will matter when we configure the SMB share.
ZFS as a Paranoid Librarian
Before touching a command, it helps to understand how ZFS thinks about data. When you hand ZFS a file, it doesn’t just write it to disk. It calculates a checksum of the data, writes the data to disk, stores the checksum separately, and verifies the checksum on every read. If they don’t match — silent bit rot, a bad disk sector, whatever caused it — ZFS knows immediately. On a mirrored pool, it can transparently read from the other copy.
The storage hierarchy goes: physical drives → VDEVs (virtual devices, which define the redundancy strategy) → Zpool (the pool of VDEVs) → Datasets (isolated filesystems within the pool, each with their own settings) → SMB share (the network-accessible mount point).
The ARC lives in RAM and caches frequently and recently accessed data. When you pull a file over SMB, ZFS checks RAM first. Cache hit means the data comes back at RAM + network speed, completely bypassing the spinning disks. This is why 32GB or 64GB of RAM in a NAS isn’t excessive — it’s the performance multiplier that makes old HDDs bearable.
Forging the Zpool: Mirror, Not Stripe
When you have two drives, there’s a tempting option: stripe them (RAID 0) and get double the capacity and double the sequential speed. Don’t. If a single sector fails on either drive, the stripe’s mathematical continuity breaks and all data on both drives is gone. Permanently.
The right choice is a mirrored VDEV (RAID 1). Every block of data is written identically to both drives. When TrueNAS creates the pool through its UI, it runs a variant of this:
zpool create -f -m /mnt/tank tank mirror /dev/sda /dev/sdb
zpool status tankOne underappreciated benefit of mirrored VDEVs over parity-based RAID (like RAIDZ1): expansion is clean. When you want more storage later, buy two more drives, add a new mirror as a second VDEV, and the pool stripes across both mirrors. Capacity doubles. IOPS double. No rebuild required.
Carving Out the Dataset
Never dump files directly into the root of a Zpool. Datasets act as isolated filesystems within the pool, each with their own compression settings, quotas, and permission models. Mixing data at the root level means you can’t apply different settings to different use cases.
zfs create tank/vault
# LZ4 compression uses idle CPU cycles to reduce data before writing.
# On slow HDDs, this actually increases effective write speed because
# less data hits the disk spindles.
zfs set compression=lz4 tank/vault
# SMB shares need NFSv4 ACLs for proper Windows compatibility.
# POSIX permissions (chmod 777) don't map cleanly to Windows ACL semantics.
zfs set acltype=nfsv4 tank/vault
zfs set aclinherit=passthrough tank/vaultThat last part matters. If you set acltype=nfsv4 on the dataset but then run chmod 777 on a folder from the TrueNAS shell, you corrupt the Windows ACLs that ZFS is tracking. Always manage SMB permissions through the TrueNAS UI’s ACL editor once you’ve configured the dataset. Don’t mix the two permission models.
The Samba Configuration Under the Hood
When you create an SMB share in TrueNAS’s UI, it injects a configuration block into /etc/samba/smb.conf. Knowing what it generates helps when things go wrong:
[VaultShare]
path = /mnt/tank/vault
hide dot files = yes
guest ok = no
read only = no
browseable = yes
vfs objects = zfs_space zfsacl
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = trueguest ok = no enforces authentication before anyone can browse the share. The vfs objects = zfs_space zfsacl line is what makes Windows ACLs propagate correctly through Samba to the underlying ZFS layer — it’s what lets you set “Allow Write” in the TrueNAS UI and have it actually work for your Windows clients.
ARC, ZIL, and the Write Speed Mystery
You’ll notice something odd when transferring large files: the copy starts at 110 MB/s, then after a few seconds drops to 30 MB/s. This is the ZIL at work.
By default, ZFS handles asynchronous writes by buffering data in RAM and flushing to disk in large, efficient batches. But some applications demand synchronous writes — the system must guarantee data is on persistent storage before acknowledging the write. Database writes are the common case. ZFS handles these by writing to the ZFS Intent Log (ZIL) on the hard drives before returning.
The problem: spinning HDDs have terrible random write IOPS. Synchronous writes to the ZIL on an HDD are slow, and when the ARC write buffer fills up, your transfer speed collapses to what the HDD can sustain with random writes.
The enterprise fix is a small, very fast NVMe SSD added as a SLOG (Separate Intent Log). The SLOG intercepts synchronous writes at NVMe speeds, freeing the HDDs for bulk sequential work. For a home NAS mostly handling file transfers, you may not need it — but if you’re running databases on your TrueNAS server, it’s worth considering.
RAIDZ1 and the Resilver Trap on Aging Hardware
If you opt for RAIDZ1 (similar to RAID5, one drive can fail) with large drives on old hardware, there’s a specific danger worth understanding. When a drive fails in RAIDZ1, you must insert a new drive and resilver — reconstruct the missing data by reading every single bit from the surviving drives.
On a 4TB RAIDZ1 array, that’s potentially terabytes of sustained sequential reads from drives that may already be near end-of-life. This prolonged stress is precisely when old drives tend to fail. If a second drive dies during resilver, you lose everything.
Mirrored VDEVs avoid this. Replacing a failed drive in a mirror just copies data from the surviving mirror at whatever speed the drives can sustain — no complex parity reconstruction, much less stress on the surviving hardware.
The 50% capacity loss with mirroring hurts, but on aging hardware that can’t afford a resilver failure, it’s the right trade. Buy two more drives when you need capacity, not one bigger drive and a complicated rebuild.
