How to Build a DIY NAS with SnapRAID and MergerFS

SnapRAID MergerFS is a Linux storage combination that pools multiple independent hard drives into one large mount point while protecting them with scheduled, snapshot-style parity, giving you a flexible DIY NAS without the rigidity of traditional RAID.

If you have a pile of mismatched drives and a spare desktop, a snapraid mergerfs build is the cheapest honest path to a real NAS. (For a deeper look at SnapRAID specifically before combining it with MergerFS, see what SnapRAID actually is and how its parity model works.) It turns a home server into bulk storage that behaves like one giant volume, with fault tolerance layered on top through parity files rather than striping.

We have run this setup for years on cheap consumer hardware, and the appeal never changes. Every disk keeps a normal filesystem, every file stays readable on its own, and adding capacity means plugging in a drive and editing two config files.

The tradeoff is simple: you accept parity that updates on a schedule instead of in real time, and in exchange you get mixed drive sizes, low RAM usage, and disks that can be pulled and read in any other Linux machine. That is a great deal for archival data, large datasets, and public domain archives that rarely change.

What follows is the full build: disk layout, filesystem prep, pooling, parity configuration, automation, and a recovery drill so data integrity is something you have verified rather than assumed.

How SnapRAID MergerFS Fits Together

These are two independent tools doing two unrelated jobs: one presents your data drives as a single mount point, the other calculates parity so a dead disk can be rebuilt. Neither depends on the other, which is exactly why the pair survives hardware changes so gracefully.

MergerFS Creates One View of Independent Disks

MergerFS is a FUSE union filesystem. It takes /mnt/disk1, /mnt/disk2, and /mnt/disk3 and exposes them as one storage pool at a single mount point such as /mnt/storage.

Nothing is striped or split. A file written into the mergerfs pool lands whole on exactly one of the data disks, and the mergerfs mount simply routes reads to whichever disk holds it.

Pull a disk out, plug it into any Linux box, and the files are right there in a normal directory tree.

SnapRAID Adds Scheduled Parity and Checksums

SnapRAID computes parity across your data disks and writes it to a dedicated parity drive. Run snapraid sync and it updates parity plus per-file checksums for everything that changed since the last run.

Those checksums are the underrated part. Scrubs read data back and compare hashes, so silent bit rot gets caught while parity can still repair it.

With one parity disk you survive one dead data disk. Add a second parity disk and you survive two.

Why This Is Not Traditional RAID or a Backup

Traditional RAID, mdadm, LVM, RAID5, RAID6, and ZFS mirrors all maintain real-time redundancy. SnapRAID does not. Anything written after the last sync has no parity protection yet.

Parity is fault tolerance, not a backup. It does not protect against fire, theft, or a script that deletes the wrong directory an hour before sync runs.

Plan the Disks and Filesystem Layout

Good layout decisions made before formatting save hours later. The rules that matter most are parity sizing, one filesystem per disk, and mount points that never shift between reboots.

Choose Data and Parity Drive Sizes

The single hard rule: each parity drive must be at least as large as your largest data drive. Mixed data disk sizes are fine, so a 20TB parity disk can protect 8TB, 12TB, and 20TB data disks together.

Buy the biggest disk you own as parity, or buy parity first and size data drives under it. CMR drives are worth the premium here, since SMR disks crawl during rebuilds.

For a first build, three data disks plus one parity disk is a comfortable ratio. Once you pass six data disks, add a second parity drive.

Format and Label Each Data Disk

Every HDD gets its own partition and its own filesystem. There is no array to create.

sudo parted /dev/sda --script mklabel gpt mkpart primary 0% 100%
sudo mkfs.ext4 -m 0 -L disk1 /dev/sda1

We use ext4 for data disks because it is boring, universal, and recoverable anywhere. XFS is a reasonable alternative for parity, and -m 0 reclaims the reserved 5 percent you do not need on bulk storage.

Repeat for each data disk and the parity disk. SSDs belong to the OS or to a staging area, not to the parity set.

Create Stable Mount Points With UUIDs

Device names like /dev/sdb reorder on reboot. UUIDs do not.

lsblk -f
sudo blkid
sudo mkdir -p /mnt/disk{1,2,3} /mnt/parity1 /mnt/storage

Then add each disk to /etc/fstab:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/disk1 ext4 defaults,noatime 0 2
UUID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /mnt/parity1 ext4 defaults,noatime 0 2

Run sudo mount -a and confirm with lsblk. This works identically on Ubuntu 24.04, Debian, and Linux Mint. Windows is not part of this build; it cannot read the pool natively.

Install and Configure the Storage Pool

With disks mounted individually, the pool itself is one fstab line plus a handful of options. The choices that actually affect daily behavior are the create policy, the free-space floor, and file ownership.

Install the Required Packages

sudo apt update
sudo apt install mergerfs snapraid smartmontools

Check versions with mergerfs --version and snapraid --version. On older Debian releases the packaged mergerfs lags badly, so grab the current .deb from the project’s releases page instead.

Build the MergerFS Mount

Add the pool to /etc/fstab below the individual disk entries:

/mnt/disk* /mnt/storage fuse.mergerfs defaults,nonempty,allow_other,use_ino,cache.files=off,dropcacheonclose=false,category.create=epmfs,minfreespace=100G,moveonenospc=true,fsname=mergerfs 0 0

Mount it with sudo mount /mnt/storage and verify with df -h /mnt/storage. The reported size should be the sum of your data disks, parity excluded.

Note the branch glob /mnt/disk*. New disks join the storage pool the moment they are mounted under that pattern.

Select a File Placement Policy

The create policy decides which data drive receives a new file.

• category.create=epmfs (existing path, most free space) keeps related directories together on one disk, which limits how many disks spin up per read.
• category.create=mfs always picks the most free space, giving even fill but scattering folders.
• category.create=pfrd distributes randomly, weighted by free space, which spreads wear nicely across a large pool.

We default to epmfs for archival data. Pair it with minfreespace=100G so mergerfs stops filling a nearly full disk, and moveonenospc=true so a write that runs out of room relocates instead of failing.

Set Permissions Without Hiding Disk-Level Access

Ownership is set on the underlying disks, not the pool.

sudo chown -R youruser:youruser /mnt/disk1 /mnt/disk2 /mnt/disk3
sudo chmod -R 775 /mnt/disk1 /mnt/disk2 /mnt/disk3

Keep writing through /mnt/storage and keep reading directly from /mnt/diskN available for troubleshooting. When a media library or archival index behaves oddly, checking the real disk path is the fastest way to see where a file physically lives.

Set Up Snapshot Parity Protection

Parity configuration lives in one file. Getting the content file placement right matters as much as the parity path, because losing every copy of the content database makes parity useless.

Create a Clear snapraid.conf Configuration

Edit /etc/snapraid.conf:

parity /mnt/parity1/snapraid.parity

content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content

data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

exclude *.unrecoverable
exclude /tmp/
exclude lost+found/
exclude .Trash-*/
exclude *.bak
exclude /snapraid.content*

Every data line points at a real disk mount, never at /mnt/storage. Pointing SnapRAID at the mergerfs pool is the classic beginner mistake and it breaks recovery.

The d1, d2, d3 names are permanent identifiers. Do not rename them later.

Place Content Files and the Parity File Safely

Parity data goes on the parity drive and nowhere else. That disk holds no user files.

Content files are the checksum database, and SnapRAID wants several copies. Keep one on the OS drive plus one on at least two data disks, so a single disk loss never takes out the whole set.

Second parity, when you add it, is another line:

2-parity /mnt/parity2/snapraid.2-parity

Run the First Sync and Verify Protection

Load your archival data onto the pool first, then protect it:

sudo snapraid sync

The first pass is slow. Roughly 20TB across four disks took us most of a day on SATA drives, and it is disk-bound, not CPU-bound.

When it finishes, confirm the state:

sudo snapraid status
sudo snapraid diff
sudo snapraid scrub -p 5

A healthy snapraid status reports zero unsynced files and no errors. Run snapraid check occasionally for a full read-and-verify pass without repairing anything.

Automate Maintenance and Verify Recovery Readiness

Parity that is a month stale protects a month-old array. SnapRAID maintenance is three habits: review changes, sync on a schedule, and scrub a slice of the array regularly.

Review Changes Before Each Daily Sync

snapraid diff prints added, removed, updated, and moved counts before anything is written. A daily sync that suddenly reports 40,000 deletions is a warning, not a task.

Set a deletion threshold in your automation and abort the sync when it is exceeded. That one guardrail is what preserves your ability to run snapraid fix after an accidental mass delete.

Community maintenance scripts handle this well and email the diff summary. Writing your own wrapper is fine too; the logic is short.

Schedule Syncs and Scrubs With systemd Timers

Cron works, but systemd timers give better logging through journalctl.

/etc/systemd/system/snapraid-sync.service:

[Unit]
Description=SnapRAID sync

[Service]
Type=oneshot
ExecStart=/usr/bin/snapraid sync
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/snapraid-sync.timer:

[Unit]
Description=Nightly SnapRAID sync

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

Enable it with sudo systemctl enable --now snapraid-sync.timer. Add a second timer running snapraid scrub -p 8 -o 10 weekly, which verifies about eight percent of blocks older than ten days and rotates through the whole array over time.

Monitor Disk Health and Test a Recovery

Install smartmontools and let it watch the drives:

sudo smartctl -a /dev/sda
sudo smartctl -t long /dev/sda

Reallocated sector counts and pending sectors climbing over weeks mean order a replacement now. SMART rarely predicts sudden failure, but it does flag slow decay.

Then rehearse. Unmount a data disk, delete a test directory from it, and run snapraid fix -d d3 -l /var/log/snapraid-fix.log. A recovery you have never performed is not a recovery plan, and this is the check most home lab builders skip.

Use the Pool Safely With Home-Lab Services

The storage pool is excellent for large, static files and poor for anything writing constantly. Splitting workloads correctly is what keeps parity meaningful and shares fast.

Keep Frequently Changing Data Outside Snapshot Parity

Databases, container volumes, and virtual machine images churn between syncs, so their parity is stale the moment it is written. Restoring one produces a corrupt file, not a working one.

Put Docker volumes, application configs, and any live database on an SSD outside the SnapRAID set, and back those up with normal snapshots or file-level backups.

The pool then holds what it is good at: high-resolution media, public domain archives, disk images, Linux distributions, and long-term datasets.

Share Archival Data Over the Local Network

Export the mergerfs mount, never the individual data drives.

[storage]
   path = /mnt/storage
   read only = no
   valid users = youruser

Samba covers mixed-client networks; NFS is faster for Linux-only home lab traffic. Docker containers should bind-mount subdirectories of /mnt/storage so a media server or archival indexer sees one continuous library.

Add mergerfs to the container’s mount propagation settings if new disks appear while services are running.

Expand Capacity and Replace a Failed Disk

Growing the pool takes three steps: format the disk, mount it under /mnt/disk4, add a data d4 line to snapraid.conf, then sync. MergerFS picks it up automatically thanks to the glob.

Replacing a dead disk is nearly the same. Mount the new drive at the old path, then run snapraid fix -d d2 and let parity rebuild that disk’s contents while every other disk keeps serving reads.

Once the capacity is in place, filling it responsibly matters. For pulling down large public domain archives and open-source datasets at line speed with SSL encryption and long retention, a premium provider such as Newshosting or Easynews is worth the few dollars a month, and datahoarder.io covers provider comparison in more depth if you are still choosing.

More DIY NAS guides

• DIY NAS build guide (start here)
• What is SnapRAID?
• SnapRAID vs Unraid
• ZFS vs BTRFS
• Best NAS cases
• Shucking hard drives
• IronWolf vs WD Red
• 4-bay vs 8-bay NAS

Frequently Asked Questions