Setting Up Bind Mounts and Overlay Filesystems

Bind mounts and OverlayFS solve two related but distinct problems: making the same underlying storage appear at a different path, and layering a writable directory on top of read-only content without modifying the original. Both are ordinary VFS features usable directly with the mount command, entirely independent of any container runtime — understanding them directly demystifies a good portion of how container storage actually works underneath.

Bind mounts: the same content, a different path

A bind mount doesn’t create new storage — it makes an existing directory (or file) accessible at a second path, with both paths referring to the literal same underlying inode:

mount --bind /data/shared /var/www/html/shared

After this, /var/www/html/shared and /data/shared are the same content — a file created, modified, or deleted through either path is immediately visible through the other, because they’re not two copies kept in sync, they’re two paths to the identical inode.

Why this is genuinely useful beyond just being a curiosity

A common, practical case: a service configured to look for files under a fixed, hardcoded path that doesn’t match where you actually want the data stored (a different disk, a different partition with more space, a network-mounted volume). Rather than reconfiguring the service (not always possible, if the path is genuinely hardcoded) or symlinking (which some software explicitly refuses to follow, or handles inconsistently), a bind mount transparently satisfies the service’s expected path while the actual storage lives wherever you want it.

Making a bind mount persistent across reboots

A mount --bind command only lasts until the next reboot unless it’s also added to /etc/fstab:

# /etc/fstab
/data/shared  /var/www/html/shared  none  bind  0  0

The none filesystem type and bind option together tell the mount system this is a bind mount, not an attempt to mount a device or partition — /data/shared here is a directory path, not a block device.

Read-only bind mounts

Adding ro alongside bind produces a bind mount that exposes the same content but disallows writes through that specific path (writes through the original path are unaffected):

mount --bind -o ro /data/readonly-assets /srv/app/assets

This is useful specifically when you want a service to be able to read shared content without being able to modify or delete it through the path it’s actually configured to use, as a safety measure independent of whatever permissions that service’s user account otherwise has on the original path.

OverlayFS: layering a writable surface on read-only content

OverlayFS combines multiple directories into a single merged view: a read-only “lower” layer (the original content, untouched), a writable “upper” layer (where any changes actually get written), and a “work” directory (required scratch space OverlayFS uses internally):

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

mount -t overlay overlay \
  -o lowerdir=/data/original,upperdir=/overlay/upper,workdir=/overlay/work \
  /overlay/merged

Accessing /overlay/merged shows the combined view of /data/original’s content — but any file created, modified, or deleted through /overlay/merged is actually written into /overlay/upper, leaving /data/original completely untouched. Modifying an existing file from the lower layer triggers a copy-up: OverlayFS copies that specific file into the upper layer first, then applies your change there, which is why the original lower directory remains pristine no matter what changes are made through the merged view.

Why this specific pattern is worth understanding directly

This lower/upper/work/merged structure is exactly the mechanism container runtimes use to give each container its own writable filesystem view on top of a shared, read-only base image — multiple containers can share the identical read-only image data (saving disk space and avoiding duplication) while each container’s own writes land only in its own private upper layer, invisible to every other container using the same base image. Understanding OverlayFS directly, outside of a container context, makes it much easier to reason about container storage behavior — why a container’s writes disappear when it’s removed (the upper layer goes with it), why disk usage doesn’t multiply per-container despite each having a full filesystem view (the lower layer is shared, not copied), and how to replicate similar layered-storage behavior for other use cases entirely unrelated to containers, like a read-only golden system image with a disposable, resettable writable layer on top of it.

Discarding changes: resetting the writable layer

Since the lower directory is never modified, discarding every change made through the overlay is simply a matter of unmounting and clearing the upper/work directories:

umount /overlay/merged
rm -rf /overlay/upper/* /overlay/work/*
mount -t overlay overlay \
  -o lowerdir=/data/original,upperdir=/overlay/upper,workdir=/overlay/work \
  /overlay/merged

This gives back a completely fresh, unmodified view of the original lower content, with the previous session’s changes discarded entirely — useful for exactly the kind of disposable, reset-to-clean-state testing environment that containers rely on this mechanism for, without needing a container runtime at all if that’s the only piece of the behavior you actually need.