Rootless Podman cannot bind ports below 1024 by default, create device nodes, run on NFS home directories, or use image UIDs outside its mapped range. Many of these limits come from kernel rules that exist for security. Check each one against your workloads before you move them rootless.
Why rootless has limits at all
Rootless mode runs the container engine and containers as an ordinary user inside a user namespace. The Linux manual notes that a process can be root inside such a namespace yet unprivileged outside it. Operations that touch the real host, such as creating devices or binding low ports, still need real privileges, so they fail. The Podman project's own page says many of its listed shortcomings are kernel restrictions in place for security reasons that Podman cannot reasonably solve.
The documented limits, in a table
| Limit | What happens | Workaround noted in the docs |
|---|---|---|
| Ports below 1024 | Bind fails, as the process lacks CAP_NET_BIND_SERVICE | Lower the unprivileged port start sysctl, or redirect from a privileged port |
| Missing subuid and subgid | Commands fail | Configure the files for the user |
| Device nodes | Creating them fails, even in privileged containers | Run as root if a container must make device nodes |
| NFS or parallel filesystem home | File creation by other UIDs is refused by the server | Use local storage |
| Images with high UIDs | Builds fail if a UID is not mapped | A standard setup maps only 65,536 IDs |
| Checkpoint and restore | Not available rootless | Needs root |
| Resource limits on cgroups v1 | Not supported | Use cgroups v2 |
The page also lists reduced functionality for a few commands, shared image stores that are hard to set up, and some systemd unit options that fail in a rootless container.
The low port example
The kernel does not let a process without the net bind capability bind below port 1024. The page shows the sysctl net.ipv4.ip_unprivileged_port_start for changing the lowest unprivileged port, for example to 443. The trade off is that the setting is system wide and applies to every user on the host. The other route the page gives is a proxy, a firewall rule or a redirect tool that sends traffic from a privileged port to an unprivileged one.
Networking changes to know about
From Podman 5.0, the page says pasta is the default networking tool. Because pasta copies the host's main interface address, connections to that address from containers do not work unless you pass a pasta configuration or have more than one interface. Rootless bridge networks use a user space port forwarder by default, which does not preserve the client's source IP. An experimental setting can switch to pasta forwarding, and it depends on a recent passt build. Treat that as something to test, not assume.
A pre migration checklist
- List the ports each workload listens on and flag any below 1024.
- Check the user has subuid and subgid ranges.
- Check where home directories live. NFS homes are a known blocker.
- Check the highest UID or GID used in your images.
- Check whether any container needs devices, checkpointing or privileged systemd options.
- Pilot one non critical workload and record what fails.
For the Docker side of rootless, see rootless prerequisites and setup, and for the mapping files see subuid and subgid explained.
Safeguard scans the dependencies and images that go into your containers regardless of runtime, with a free scan at gold.safeguard.sh/scan.
Quick check
Does rootless mean a container breakout is harmless?
No. It limits what a breakout gains on the host, because the process is an unprivileged user there. Data you mounted into the container is still reachable.
Why can a privileged rootless container not create device nodes?
The kernel does not let processes without the mknod capability create them, so a container needing devices must run as root.
Sources
Last reviewed: 19 October 2026.
