Bind Mounts, Read-Only Mounts, tmpfs, Mount Propagation, Subpaths, SELinux Labels, and Host Coupling: Configuration, Design Choices, and Tradeoffs

1. Named volume vs bind mount vs tmpfs

Do not choose a mount because it is familiar. Start from lifecycle and authority: what must persist, what must be host-visible, and what should vanish?

2. Read-only by default, writable by exception

If a container only needs configuration, templates, certificates, or source inputs, a read-only bind communicates and enforces that contract. Writable binds are appropriate when the container intentionally edits host-visible artifacts, such as a local formatter or code generator. Scope them to the smallest directory possible.

3. Development coupling versus production portability

Bind mounts are excellent for the inner loop because edits made in the editor are immediately visible to the container. Production systems are less tolerant of hidden host assumptions. A deployment that requires /home/alice/project/config to exist on every host is not self-contained. Prefer images, configs/secrets mechanisms, or managed storage where practical.

4. Propagation is not a generic “make mounts work” switch

Propagation is supported only on Linux host machines and does not work with Docker Desktop. If you cannot state the nested-mount requirement precisely, keep the default.

5. SELinux: shared label versus private label

z tells Docker the content may be shared among containers; Z assigns a private container-oriented label. Both can relabel host files. This is a security-sensitive host mutation, so use it only on the exact intended application directory. Never apply Z to broad operating-system trees.

6. Compose can hide source-creation semantics unless you inspect the model

Compose long syntax exposes bind options including propagation, create_host_path, and SELinux labeling. Current Compose documentation states create_host_path defaults to true. If silent creation is not acceptable, set it explicitly to false where supported and inspect docker compose config before up.

services:
  app:
    image: busybox:1.36.1
    command: ["sleep", "300"]
    volumes:
      - type: bind
        source: ./config
        target: /app/config
        read_only: true
        bind:
          create_host_path: false
      - type: tmpfs
        target: /run/app
        tmpfs:
          size: 1048576
          mode: 1770

7. Worked decision table

8. Keep adjacent state categories separate

Mount configuration does not fix application listening, network reachability, image identity, authentication, or external storage authorization. Likewise, an image rebuild does not change a host bind source. Diagnose the layer that owns the evidence.

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.