OverlayFS is a union filesystem that presents two or more directories as a single view. It uses a lower, read-only layer and an upper, writable layer, then merges them at runtime so files appear combined. In Linux containers and images, it helps isolate filesystem changes while keeping the base layer intact.
How OverlayFS Works
OverlayFS combines multiple directories into one logical filesystem view by layering a writable upper layer over one or more lower layers. For container images and root filesystems, that means the base content can stay intact while changes are written elsewhere, which makes the merged view feel seamless to the process using it.
The key idea is copy-on-write behaviour at the file level. When a file from a lower layer is modified, the change is written to the upper layer instead of altering the original layer directly. That preserves image immutability, speeds up cloning of environments, and lets multiple containers share the same underlying read-only content.
Why OverlayFS Matters in Containers
OverlayFS is central to how many Linux container runtimes present a writable filesystem without duplicating the entire base image. It reduces storage overhead, supports rapid start-up, and helps separate image content from runtime state. In practice, that separation is one reason containers can be launched, stopped, and discarded without mutating the original image.
This layering model also shapes operational behaviour. A container may appear to have a complete filesystem, but only the upper layer contains its local changes. Administrators need to remember that a file visible inside a container may actually be inherited from a lower layer, which matters when debugging, auditing, or comparing what was changed during runtime.
Filesystem Semantics and Limitations
OverlayFS does not behave like a normal single-directory filesystem underneath, even though it presents one unified view to applications. Directory precedence, file masking, whiteouts, and copy-up behaviour can make the merged result differ from a simple concatenation of paths. Those semantics are useful, but they can surprise tooling that assumes direct one-to-one storage layout.
Because the upper and lower layers are distinct, access patterns can also affect performance and visibility. A read may come from a lower layer, while a write triggers copy-up into the upper layer. That means the runtime state of a container is not just “the file system”, but the result of a merge policy that has to be understood when troubleshooting storage, permission, or path-resolution issues.
Security Implications for Layered Filesystems
OverlayFS itself is not a security control, but it influences the trust boundary between base images and runtime changes. If the base layer is trusted and the writable layer is not tightly governed, an attacker or misconfigured workload can introduce changes that persist for the life of the container and may be hard to distinguish from image content.
It also affects how defenders reason about integrity. A container image scan may describe the lower layers accurately while missing runtime additions in the upper layer. That is why operators should treat the merged filesystem view as an active state that can differ from the published image, especially when investigating tampering, unexpected binaries, or altered configuration files.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | OverlayFS affects image-layer baselines and runtime drift control. |
| SI-7 — Software, Firmware, and Information Integrity | Layered filesystems can hide tampering in the writable overlay. | |
| Recommendation — Define approved base-image baselines and compare runtime layers against them. Verify filesystem integrity and investigate unexpected overlay changes. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | OverlayFS is part of container and host configuration hardening. |
| CIS-12 — Network Infrastructure Management | Container runtime storage and layering are part of managed platform configuration. | |
| Recommendation — Harden container and host filesystem settings to reduce unexpected mutation. Document and review platform filesystem behaviour as part of secure administration. | ||
Practitioner Guidance
What to watch for: Treat OverlayFS as a filesystem composition mechanism, not as a security boundary. The practical question is whether your tooling, runtime policy, and incident review process can see both the immutable image layers and the mutable upper layer as separate sources of truth.
Governance implication: Container operators should know which paths are expected to come from the base image and which are expected to change at runtime. That distinction improves image hygiene, makes drift easier to spot, and helps explain why a container’s visible filesystem may not match the original artifact exactly.