Sooner or later, every self-hosted setup runs into the same wall: you need more storage, but you don't need a distributed storage cluster.
Maybe you have a media server whose library keeps growing, or a backup target that's slowly filling up, or a homelab with three or four machines that each have some spare disk sitting idle.
The obvious answers, Ceph, GlusterFS, or a full-blown SAN, are overkill for this kind of problem.
They bring their own operational burden: multiple daemons, quorum requirements, network overhead, and a learning curve that doesn't pay for itself unless you're running dozens of terabytes across a real cluster with redundancy requirements.
This is the gap that MergerFS fills.
It's a union filesystem, meaning it takes several separate storage locations and presents them to applications as a single, unified mount point.
It doesn't stripe data, it doesn't replicate it, and it doesn't do anything clever with erasure coding.
It just merges directory trees.
Combined with NFS to bring in storage from a second machine, you can build a pool that behaves like one big disk without touching a single line of cluster configuration.
This article walks through building exactly that: an NFS server exporting a chunk of storage, a client machine mounting it locally, and MergerFS combining that NFS mount with local disk into a single pooled filesystem.
Along the way we'll cover the NFS version choice, placement policies, permissions, failure behavior, and backup strategy, because a union filesystem is not, and never will be, a backup.
Before going further, it's worth being honest about when this approach doesn't make sense.
If you need strong consistency guarantees, POSIX locking across multiple concurrent writers, or high availability where a node failure shouldn't interrupt service, MergerFS and NFS are the wrong tool.
This setup is best suited for single-writer or mostly-read workloads: media libraries, backup targets, file archives, and general-purpose homelab storage where simplicity and low operational overhead matter more than clustering guarantees.
Architecture Overview The setup involves two machines.
One exports storage over NFS, the other mounts that export and merges it with its own local disk using MergerFS.
Applications on the client only ever see the final merged mount point; they have no idea whether a given file physically lives on local disk or on the remote NFS share.
Data flows in one direction conceptually: applications write to (the merged mount), MergerFS decides which underlying branch actually receives the write based on the placement policy you configure, and that branch is either local disk or the NFS mount pointing back at the storage server.
Reads work the same way in reverse; MergerFS looks across all branches and presents whichever file matches, regardless of where it physically lives.
Requirements You'll need two Linux machines for this setup.
The first is the storage server, whose only job is to export a directory over NFS.
The second is the application or client server, which mounts that export and merges it locally with MergerFS.
Both machines can run any mainstream distribution; the commands below cover Debian and Ubuntu (using ), and Arch Linux (using ), with notes for Fedora and Rocky Linux where the package names differ.
In terms of hardware, there's nothing exotic here.
A gigabit or better network link between the two machines is recommended if you're moving anything beyond small files, since NFS performance is heavily influenced by network latency and throughput.
For the examples in this article, the storage server sits at and the application server sits at .
These addresses come from RFC 5737 and are reserved for documentation, so don't expect to reach them on the internet.
Installing and Configuring the NFS Server Start on the storage server.
On Debian or Ubuntu: On Arch Linux: On Fedora or Rocky Linux, the package is as well, installed with .
Next, create the directory you intend to export and lock down its ownership.
This directory will hold the actual data, so treat its permissions carefully from the start: On Arch and Fedora-based systems, the anonymous group is usually called rather than ; check with if the chown command complains.
Now define the export in : Each field here matters. allows both reads and writes from the client. tells the NFS server to write changes to disk before acknowledging them back to the client, which is slower than but much safer, since can lose recently written data if the server crashes before flushing to disk. disables a consistency check that verifies a requested file is actually within the exported tree; it's mostly a legacy option at this point and disabling it improves reliability when files are renamed or moved within the export.
We'll come back to in the permissions section, since it interacts directly with how MergerFS on the client will see file ownership.
Apply the export and start the services: re-reads and reloads the export table without needing a full service restart, which is convenient once you're iterating on the configuration.
Verify the export is live with: You should see the export listed along with the options you configured.
From the client side, once networking is in place, you can also confirm visibility with , which lists everything the server is currently exporting.
Installing the NFS Client On the application server, install the client tools.
Debian and Ubuntu: Arch Linux: Create a mount point and test the connection manually before committing to a permanent configuration: The flag pins the mount to NFSv3, which we'll justify in detail in the next section.
If the mount succeeds, should show the remote filesystem, and you should be able to create and read files there as a basic sanity check: Common mount options worth knowing at this stage include and , which control the maximum read and write block sizes negotiated with the server (larger values generally help throughput on fast networks), and , which sets how long the client waits before retransmitting a request.
We'll cover the full set of options when we build the permanent fstab entry.
Why Choose NFSv3?
This is a question that trips up a lot of people setting up NFS for the first time, because the assumption is usually "newer is better." NFSv4 is indeed the more modern protocol, with integrated security (Kerberos support), a single well-defined TCP port instead of the sprawling portmapper dance NFSv3 relies on, and built-in state management for things like file locking.
So why would anyone deliberately choose the older version for a pooled storage setup?
The core difference comes down to statefulness.
NFSv3 is stateless: the server keeps no record of which clients have which files open.
Every request is self-contained and includes everything needed to process it.
NFSv4 is stateful: the server tracks open files, locks, and client sessions as ongoing state.
Statelessness sounds primitive, but it has a very practical benefit for a setup like this one.
When an NFSv3 server reboots or the network briefly drops, there's no session state to recover; the client simply resumes sending requests once the server is reachable again, and the server has no confusion about what it "should" remember.
NFSv4, by contrast, needs to go through a grace period after a restart where it reclaims locks and rebuilds session state, and if that recovery is interrupted or misconfigured, clients can end up stuck.
Locking behavior follows from this.
NFSv3 relies on a separate protocol, NLM (Network Lock Manager), running alongside the main NFS service, which is part of why NFSv3 needs the portmapper and multiple ports.
NFSv4 has locking built directly into the protocol, which is architecturally cleaner but ties lock state to the stateful session model described above.
For a MergerFS pool that's primarily serving media files, backups, or archival data with a single writer at a time, the sophistication of NFSv4 locking rarely ge