Permission denied on named volumes with user namespace remapping

When deploying containers to production environments that utilize user namespace remapping, named volumes often result in 'permission denied' errors that do not appear during local development. This typically occurs when the Docker daemon is configured with userns-remap in the daemon.json file.

In a rootless or remapped environment, the container's root UID 0 is mapped to a high-range host UID (e.g., 100000). If the volume was initialized by a process running without remapping, or by a different user, the filesystem ownership may not align with the remapped UID expected by the containerized process.

There is a lack of clear documented behavior regarding how Docker handles ownership migration for existing volumes when remapping is toggled post-creation. It is unclear if the engine attempts a recursive ownership adjustment at mount time or if manual host-side intervention is the only supported path.

• Does Docker automatically adjust UID ownership for existing volumes when a user namespace map is enabled?
• What is the recommended mechanism to synchronize host-side permissions with remapped UIDs without manual chown commands?