Docker userns-remap and bind-mounted host paths: automatic namespace reconciliation or operator responsibility?

Direct answer

Docker does not automatically re-own bind-mounted host paths when userns-remap is active. The daemon preserves the original host ownership by design, and no documented configuration flag or runtime contract shifts this responsibility to the engine. Operators must reconcile ownership explicitly—typically by pre-owning the host directory to a UID inside the subordinate range or by using named volumes instead of bind mounts.

Why the asymmetry exists

When userns-remap is enabled, container UID 0 maps to a high-numbered host UID (for example, 100000). Named volumes are initialized with that remapped ownership, so they align automatically. Bind mounts, however, present the host directory as-is. The daemon does not rewrite inode ownership during docker run or docker create.

This boundary is deliberate. Automatically changing host file ownership at mount time would require the daemon to write to arbitrary host paths, which conflicts with least-privilege deployment models and could expose host files to the container with elevated privileges. On a native Linux daemon, the storage driver—whether overlay2, aufs, or others—does not alter this behavior; the ownership rule is enforced at the mount layer, not the storage layer. These observations apply to Docker Engine versions that support userns-remap; the daemon-side rule has been consistent, though exact VM behavior on Docker Desktop is version-dependent.

Confirmed behavior versus likely explanation

Confirmed: bind mounts retain host ownership; named volumes receive remapped root ownership; no daemon flag auto-reowns bind mounts.

Likely: the design protects host filesystem integrity and avoids granting the daemon broad write access to host directories. This is an architectural boundary rather than a bug.

Steps for this case

1. Confirm remapping is active and note the subordinate range:

   docker info | grep -i userns

2. Inspect the host directory ownership:

   ls -ln /host/dir

3. If the host directory is owned by a UID outside the subordinate range, change it to the mapped UID (for example, 100000):

   sudo chown 100000:100000 /host/dir

4. Re-run the container and verify the effective UID inside:

   docker run --rm -v /host/dir:/mnt busybox id -nu

5. If pre-owning is not acceptable, replace the bind mount with a named volume.

Docker Desktop caveat

On macOS and Windows, the daemon runs inside a Linux VM and host paths are shared into that VM. The shared-folder implementation may present different ownership semantics, so the native-Linux mismatch may not appear in the same form. Behavior there depends on the VM's file-sharing layer, not the OCI runtime's namespace mapping alone.

Missing diagnostic detail

Are you running a native Linux daemon or Docker Desktop? The answer determines whether the bind-mount mismatch is governed by the host filesystem directly or by the VM's shared-folder layer, which changes the remediation path.