8.1 Container Filesystem

A container's filesystem is the complete, unified view of files a running container sees, constructed by layering its own writable layer on top of all of the underlying image's read-only layers, presenting what appears to be a single, ordinary filesystem despite this underlying layered structure.

How the Unified View Is Constructed

A union filesystem mechanism combines every layer — the image's read-only layers plus the container's own writable layer — into a single, coherent view, with files from higher (more recent) layers taking precedence over identically named files in lower layers.

docker run -d --name myapp myapp:1.0
docker exec myapp ls /app

This reflects the fully merged view across every contributing layer, appearing to the running application as an entirely ordinary filesystem.

Reading Files Doesn't Require Copying Them

When a container reads a file that exists in one of the image's read-only layers, it reads directly from that layer without needing to copy the file into the writable layer first.

docker exec myapp cat /app/config.yaml

This reads directly from whichever layer actually contains config.yaml, without modifying anything.

Modifying a File Triggers Copy-on-Write

Writing to a file that originates in a read-only layer triggers a copy-on-write operation, copying that file into the container's own writable layer before applying the modification there.

docker exec myapp sh -c "echo 'new line' >> /app/config.yaml"
docker diff myapp

This reveals the modified file now present in the container's own writable layer, distinct from the original, unmodified version still present in the underlying image layer.

Why Understanding the Container Filesystem Matters

Recognizing that a container's apparently ordinary filesystem is actually a carefully constructed, layered view — with reads served from whichever layer holds the relevant content, and writes always directed to the container's own writable layer — clarifies both how Docker achieves efficient layer sharing across containers and why a container's actual filesystem changes are always confined to its own separate writable layer.