Plan host-file ownership before enabling Docker user namespace remapping

Container root can map to an unprivileged host identity while the Docker daemon still runs as root.

Source facts

Docker userns-remap maps container user IDs to subordinate host IDs. This reduces the host privilege of container processes but does not make the daemon rootless. Docker notes that bind-mounted host resources need coordinated permissions for the mapped user. It also warns that enabling remapping changes access to existing Docker objects through a different storage arrangement.

Source: Docker documentation — Isolate containers with a user namespace.

Applicability

This concerns Docker daemon user-namespace remapping. It is not the same deployment model as Docker rootless mode and does not eliminate daemon privilege.

DSE recommendation

DSE recommends recording the subordinate UID and GID ranges and checking every required host path before enabling remapping. Avoid solving ownership failures with world-writable permissions. Plan the migration of existing containers, images, and volumes and preserve the original recovery path. Keep mapped identity ranges from colliding with other host allocations. Review backup and restore procedures because restored numeric ownership must still match the intended mapping when the workload returns.

Verification

In a nonproduction host, inspect effective IDs inside and outside a test container. Verify approved bind-mount reads and writes and confirm unrelated host data remains inaccessible. Recreate and restore a disposable workload under the mapped configuration before applying the migration to production state. Preserve the mapped numeric owner of the restored sample file and compare it with the reviewed UID/GID allocation. Have the host owner approve any permission adjustment instead of accepting a broad mode change just to make the application start.

Official reference

Docker documentation — Isolate containers with a user namespace. Reviewed October 20, 2026.