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

When Docker Engine runs with userns-remap enabled, container UID 0 maps to a high-numbered host UID, but bind-mounted host files retain their original host ownership. This creates an asymmetry: named volumes are initialized with the remapped root ownership, while bind mounts are not automatically re-owned, often leading to permission mismatches inside the container. The daemon does not rewrite host directory IDs during docker run or docker create, leaving an unresolved boundary between the runtime and the host filesystem.

The behavior is version-sensitive because the subordinate UID/GID range and storage driver interact with the OCI runtime, and changing the remap configuration alters how existing bind mounts are interpreted. Docker Desktop on macOS and Windows further abstracts the host filesystem through a VM, so the same bind-mount ownership semantics may not apply as they do on a native Linux daemon. The core uncertainty is whether the runtime should reconcile host file ownership automatically at mount time or whether this reconciliation should remain an explicit operator responsibility.

Should Docker automatically re-own bind-mounted host paths to match the active user namespace at mount time, or should the daemon continue to preserve host ownership and require operators to manage the mapping themselves? How do the subordinate ID range and storage driver choices affect this boundary on native Linux versus Docker Desktop? Is there a documented configuration or runtime contract that defines where this reconciliation responsibility belongs?