Bind Mounts, Read-Only Mounts, tmpfs, Mount Propagation, Subpaths, SELinux Labels, and Host Coupling: Concepts, Architecture, and Mental Model

1. The practical problem: storage convenience can become host authority

Chapter 20 separated persistent data from the container lifecycle with Docker-managed volumes. Bind mounts solve a different problem: they expose a path that already exists on the daemon host directly inside a container. That is ideal for source-code editing, test fixtures, local configuration, and selected host integrations, but it couples the workload to a particular host filesystem layout and permission model.

The important question is not merely “is there a mount?” It is: which host path, on which daemon host, with what write authority, under what Linux security labeling and propagation rules, and for how long?

2. Mental model: daemon-host path → mount policy → container namespace → side effect

The Docker client submits a mount specification to the daemon selected by the active context. For a bind mount, the daemon resolves the source on its own host. The runtime places that source at a target inside the container mount namespace. Read-only mode can block container writes; propagation can control visibility of nested mounts on supported Linux hosts; SELinux may authorize or deny the access based on labels; and user IDs still govern ordinary filesystem permission checks.

flowchart TD
  C[Docker client + active context] --> D[Docker daemon host]
  D --> S[Source path on daemon host]
  S --> M[Mount configuration target + ro/rw + propagation]
  M --> L[LSM + UID/GID policy]
  L --> N[Container mount namespace]
  N --> A[Application access]
  A --> H[Host-visible side effect for writable bind]
  D --> T[tmpfs allocation]
  T --> N
  T --> X[Discarded when container stops/removes]
            

3. State to identify before any mutation

4. Read-only inspection first

Before mounting anything, confirm the context and the exact host path. Then inspect existing mounts without modifying them.

docker context show
docker context inspect "$(docker context show)" --format '{{json .Endpoints.docker.Host}}'

docker ps -a --format 'table {{.ID}}	{{.Names}}	{{.Image}}'

docker inspect <container-name> --format '{{json .Mounts}}' 2>/dev/null || true

On a local Linux Engine, the daemon host may be the same machine as the client. On Docker Desktop, the daemon runs in a Linux VM and Desktop forwards approved native host paths. With a remote context, the remote daemon cannot directly bind files that exist only on the client.

5. Bind, volume, and tmpfs solve different state problems

A read-only bind reduces write authority but does not remove information exposure: the container can still read whatever the source contains. Least privilege therefore means both narrow source scope and the least required access mode.

6. Why --mount is the safer teaching default

Current Docker documentation recommends --mount for clarity. By default, a missing bind source causes an error. The shorter -v form creates a missing source directory automatically, which can hide a typo. Engine 29.3 added the explicit bind-create-src option so source creation can be intentional even with --mount.

7. tmpfs is ephemeral and memory-accounted

A tmpfs mount has no source path. Files live in host memory and disappear when the container stops. Current Docker documentation notes that tmpfs usage counts against the container memory cgroup limit; a large tmpfs size does not bypass memory governance.

8. SELinux labeling is not a permissions shortcut

On SELinux-enabled Linux hosts, z means shared relabeling for content used by multiple containers, while Z means private relabeling. These options modify labels on the host path itself, so they should never be applied casually to broad system directories. If SELinux denies access, diagnose labels and policy rather than disabling SELinux.

9. DevOps connection: make host coupling visible

A reproducible workload records the daemon context, source path contract, target, write mode, security labeling assumptions, ownership, and platform-specific file-sharing behavior. The image digest alone cannot reproduce a workload whose correctness depends on an undeclared host directory.

Knowledge check

Official references and version notes

• Docker Docs — Bind mounts — daemon-host paths, read-only mode, --mount versus -v, recursive mounts, propagation, and SELinux labeling.
• Docker Docs — tmpfs mounts — memory-backed lifetime, size/mode options, and cgroup memory accounting.
• Docker CLI — docker container run — mount and read-only-root-filesystem semantics.
• Compose Specification — service volumes — bind options, create_host_path, SELinux labels, tmpfs, and volume subpaths.
• Docker Docs — Volumes — volume-subpath as a mount-type-specific subpath feature and contrast with bind mounts.
• Docker Desktop — File sharing — host-to-VM sharing boundaries and performance guidance.
• Docker Desktop — Synchronized file shares — optional paid synchronized host-file caching for large repositories.
• Docker Engine 29 release notes — current Engine baseline and bind-create-src addition in 29.3.