OverlayFS vs AuFS vs UnionFS-FUSE: Choosing a Linux Union Filesystem

The decision: choose a union filesystem for layered Linux images

You need one directory tree that merges several underlying directories, typically for container image layers or a read-only base with a writable top layer. Picking the wrong union filesystem means maintaining out-of-tree kernel modules, absorbing FUSE context-switch overhead, or losing security updates with your distribution. On current Linux, the practical choice is between OverlayFS, AuFS, and UnionFS-FUSE.

Useful takeaway: start with OverlayFS if your kernel is version 4.0 or newer. It is mainline, supported by Docker and Podman, and avoids the maintenance burden of patched kernels or userspace translation layers.

Supported options and constraints

OverlayFS entered the mainline kernel in 3.18 and is standard from 4.0 onward. It is the default backend for Docker's overlay2 storage driver and is used by Podman. AuFS is not part of mainstream Linux; it requires a patched kernel or external module and is unmaintained in many distributions. UnionFS-FUSE runs in userspace through FUSE, so it works on older kernels but moves metadata and data through context switches.

Option	Kernel requirement	Distribution support	Typical use	Main limitation
OverlayFS	≥3.18, standard from 4.0	Built into major distros	Container image layers, overlay rootfs	No native snapshots; copy-up latency on first write
AuFS	Out-of-tree patch or module	Limited; often unmaintained	Legacy container runtimes	Security update lag; portability risk
UnionFS-FUSE	Any kernel with FUSE	Userspace package	Ad-hoc layered mounts on old kernels	Higher CPU overhead; lower throughput

Trade-offs that affect operations

Performance and privilege

OverlayFS resolves paths in the kernel, so reads avoid the round-trip cost of FUSE. AuFS can arrange branches more flexibly, but you may be pinned to an older kernel to keep its module compiling. UnionFS-FUSE installs without kernel changes, yet it is a poor fit for high-throughput build or database workloads because every operation crosses the userspace boundary.

Copy-up latency

All copy-on-write union filesystems copy a file from the lower layer to the upper layer on its first write. That initial write is slower than later writes to the same file. OverlayFS performs copy-up in the kernel; UnionFS-FUSE does it in userspace, which adds measurable latency.

Snapshots and rollback

OverlayFS does not snapshot the merged view itself. To back up the combined namespace, snapshot the underlying block device with LVM or a similar tool, then back up the upperdir separately. This is an operational constraint, not a defect, but it changes backup planning.

Concrete validation: confirm support and mount an overlay

Run the following as root or with sudo on the target host. Replace placeholder paths such as /srv/overlay/lower with real directories on your system.

1. Check kernel support

uname -r
cat /proc/filesystems | grep overlay

Expected result: a release such as 6.1.0 or later, plus a line containing nodev overlay. If grep returns nothing, the kernel lacks OverlayFS and you should use UnionFS-FUSE or upgrade the kernel before proceeding.

2. Create the required directories

mkdir -p /srv/overlay/lower /srv/overlay/upper /srv/overlay/work /srv/overlay/merged

The workdir must reside on the same filesystem as upperdir. OverlayFS uses it to stage copy-up operations.

3. Mount the union view

mount -t overlay overlay -o lowerdir=/srv/overlay/lower,upperdir=/srv/overlay/upper,workdir=/srv/overlay/work /srv/overlay/merged

This requires CAP_SYS_ADMIN or root. After the mount succeeds, files under lower appear inside merged. New files created under merged are written to upperdir.

4. Verify copy-up behavior

echo 'base content' > /srv/overlay/lower/base.txt
cat /srv/overlay/merged/base.txt
echo 'overlay content' > /srv/overlay/merged/base.txt
ls /srv/overlay/upper

Expected check: the second cat displays the modified content, and ls lists base.txt under upperdir, confirming the file was copied up from the lower layer.

When to choose each option

• OverlayFS: Default for new container workloads, CI runners, and systems on a supported kernel. Works with Docker overlay2 and Podman without extra modules.
• AuFS: Only for legacy infrastructure that already depends on it. Do not start new projects on AuFS; module maintenance and kernel compatibility become your operational burden.
• UnionFS-FUSE: Temporary workaround on locked-down or very old kernels where modules cannot be loaded. Accept the throughput penalty and plan to migrate.

Limitations and rollback

Unmounting the merged directory removes the unified view but leaves lowerdir and upperdir intact. If applications hold open files inside merged, unmount fails until those descriptors close:

umount /srv/overlay/merged

This only tears down the mount point; it does not delete data. OverlayFS has no built-in snapshot of the merged namespace, so rollback to a previous merged state requires restoring upperdir from a backup or using an underlying block-device snapshot.

Practical way to confirm the result

After mounting, run:

mount | grep /srv/overlay/merged

The output should show an overlay type mounted on the target directory. If you use Docker, confirm the storage driver with:

docker info | grep 'Storage Driver'

It should report overlay2 on a system configured for OverlayFS.