Use rootless mode when you can, because it runs both the Docker daemon and the containers without root. Use userns remap when the daemon must stay root but you still want container root mapped to an unprivileged host user. Both rely on Linux user namespaces, and both have setup costs.
What a user namespace does
The Linux manual describes user namespaces as isolating user and group IDs. A process can be an ordinary user outside the namespace and have user ID 0 inside it. Inside, it has full privileges for operations the namespace owns. Outside, it is unprivileged. That is why root in a remapped container is not root on the host.
The two modes compared
| Question | userns remap | Rootless mode |
|---|---|---|
| Does the daemon run as root? | Yes | No |
| Do containers run as root on the host? | No, mapped to a high host UID | No |
| Needs subordinate ID ranges? | Yes | Yes |
| Setuid or capability binaries | Not covered in the docs | None except newuidmap and newgidmap |
| Best moment to enable | A fresh Docker install | A user who can follow the prerequisites |
The first row is the key difference. Docker states that with userns remap the daemon still runs with root privileges, while in rootless mode both the daemon and the container run without root. If your concern is a flaw in the daemon or the runtime, rootless addresses it more directly.
Costs of userns remap
Docker's page warns that enabling it effectively masks existing images and containers under the Docker data directory, because ownership is adjusted and the objects are stored in a subdirectory. The advice is to turn it on for a new installation, not an existing one. If you disable it later, you cannot access resources created while it was on.
Bind mounts are the other pain point. When a container needs access to host paths the mapped user cannot write, you get permission problems. Docker says that from a security standpoint it is best to avoid those situations.
Costs of rootless mode
You must install newuidmap and newgidmap, usually from the uidmap package, and your user needs at least 65,536 subordinate IDs in /etc/subuid and /etc/subgid. Docker also notes that its install script is not supported on s390x. Rootless Podman documents further limits, covered in what breaks when you go rootless. The setup steps are in the rootless prerequisites post.
A decision path
- Can every user and CI job run its own rootless daemon? If yes, choose rootless.
- Do you need a shared system daemon that must run as root? Consider userns remap on a fresh host.
- Do workloads need privileged ports, devices or heavy host mounts? Expect friction in both, and test early.
- Is the code truly untrusted? Neither mode replaces a stronger boundary. See how sandboxes compare.
What neither mode fixes
A user namespace limits what a breakout gains on the host. It does not remove vulnerable packages inside the image, and it does not stop a container reading data you mounted into it.
Safeguard's scanning covers dependencies and images, not daemon configuration, and the free scan is at gold.safeguard.sh/scan.
Quick check
Is root inside a remapped container root on the host?
No. The manual describes full privileges only for operations the namespace owns. On the host the process is an unprivileged user.
Can I switch userns remap on for a host with existing containers?
You can, but Docker warns that existing images and containers are masked. Plan it for a new install.
Sources
- Rootless mode, Docker Docs
- Isolate containers with a user namespace, Docker Docs
- user_namespaces(7), man7.org
Last reviewed: 19 October 2026.
