🦭 Podman Error: 'max user namespaces exceeded' Starting a Rootless Container

Exact Error Message

Error: OCI runtime error: unable to start container process:
error during container init: unable to create new user namespace:
clone: Too many open files (max user namespaces exceeded)

On Debian-family kernels with unprivileged namespaces disabled outright, the wording differs:

ERRO[0000] running `/usr/bin/newuidmap 4821 0 1000 1 1 100000 65536`:
Error: cannot re-exec process to join the existing user namespace:
clone: Operation not permitted

What It Means

Rootless Podman is built on user namespaces. Every rootless container creates at least one, and pods and nested workloads create more. The kernel caps how many user namespaces a single user may hold via the user.max_user_namespaces sysctl, exposed at /proc/sys/user/max_user_namespaces. When you reach that cap, clone(CLONE_NEWUSER) fails with ENOSPC, which the runtime surfaces as max user namespaces exceeded — sometimes with a misleading Too many open files prefix, because the errno text does not match the real cause.

There are two distinct situations behind the same message. The first is a genuinely low or zero limit: some hardened images and Debian-derived kernels default user.max_user_namespaces to a small number, or gate unprivileged namespace creation entirely behind kernel.unprivileged_userns_clone. With that set to 0, rootless Podman cannot work at all. The second is exhaustion over time: namespaces are held by processes, and stopped-but-not-removed containers, orphaned conmon processes, and stale podman sessions keep references alive. A CI runner or a container-in-container build host will burn through a modest cap in hours even though the limit looked generous on day one.

Common Causes

• user.max_user_namespaces is set to 0 or a low value by a hardening baseline or CIS profile.
• kernel.unprivileged_userns_clone is 0 on a Debian or Ubuntu kernel, blocking unprivileged namespace creation.
• Hundreds of stopped containers still hold namespace references that were never released.
• A CI runner executes many short-lived rootless containers per job without cleanup between them.
• Container-in-container or nested Podman builds consume several namespaces per task.
• A container engine, a snap or flatpak sandbox, and Podman all compete for the same per-user cap on a shared host.

Diagnostic Commands

Read the current cap and, on Debian-family kernels, the unprivileged gate:

cat /proc/sys/user/max_user_namespaces
sysctl kernel.unprivileged_userns_clone 2>/dev/null || echo "knob not present on this kernel"

Confirm rootless namespace creation works at all, independent of Podman:

unshare --user --map-root-user echo "user namespaces OK"

Count how many containers exist versus how many are running — the gap is your leak:

podman ps -a --format '{{.Status}}' | sort | uniq -c
podman ps -aq | wc -l

Look for orphaned supervisor processes still holding namespaces after their containers stopped:

pgrep -a -u "$USER" conmon | wc -l
ls -l /proc/self/ns/user

Check which config files are setting the sysctl, since a drop-in may be overriding what you just applied:

grep -rn 'max_user_namespaces\|unprivileged_userns_clone' /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/ 2>/dev/null

Step-by-Step Resolution

1. Read the effective value. A 0 means rootless Podman is disabled outright; a low number means you are hitting a real cap:

sysctl user.max_user_namespaces

2. Raise it for the running kernel to confirm the diagnosis before making it permanent:

sudo sysctl -w user.max_user_namespaces=28633
podman run --rm docker.io/library/alpine:latest echo ok

3. Persist the setting with a sysctl drop-in so it survives reboots, and apply it without restarting:

sudo tee /etc/sysctl.d/99-podman-userns.conf <<'EOF'
user.max_user_namespaces = 28633
EOF
sudo sysctl --system

4. On Debian or Ubuntu kernels where unprivileged namespace creation is gated separately, enable that knob too — raising the count alone will not help while the gate is closed:

sudo tee -a /etc/sysctl.d/99-podman-userns.conf <<'EOF'
kernel.unprivileged_userns_clone = 1
EOF
sudo sysctl --system
sysctl kernel.unprivileged_userns_clone

5. If the cap is already generous, you are leaking rather than under-provisioned. Reclaim namespaces held by stale containers and pods:

podman ps -a --filter status=exited --format '{{.ID}} {{.Names}} {{.Status}}'
podman system prune -f
podman pod prune -f

6. Verify recovery by starting a container and re-checking that the container count has actually dropped:

podman ps -aq | wc -l
podman run --rm docker.io/library/alpine:latest sh -c 'id -u; cat /proc/self/uid_map'

For CI runners the durable fix is a cleanup step rather than an ever-higher sysctl. Add podman system prune -f to the job teardown, and make it run even when the job fails, so a red build does not leave namespaces behind for the next one. If your runner executes Podman inside a container, budget several namespaces per nested task and set the host cap accordingly — the inner engine’s usage counts against the outer user’s quota. Nested rootless setups also frequently run out of subordinate ID ranges at the same time, which produces a different error; see Podman error: insufficient UIDs in user namespace.

If unshare --user fails while the sysctls look correct, the blocker is usually the setuid helpers rather than the kernel limits; see Podman error: newuidmap exit status 1.

Prevention

• Ship user.max_user_namespaces in a versioned /etc/sysctl.d/ drop-in as part of host provisioning, not as an ad hoc sysctl -w.
• Audit hardening baselines for a rule that zeroes the sysctl before rolling them onto Podman hosts.
• Add podman system prune -f to CI job teardown and run it in an always-executed cleanup stage.
• Use --rm on every ephemeral podman run so containers do not linger after exit.
• Alert on podman ps -aq | wc -l crossing a threshold, which catches leaks long before the cap is hit.
• Size the cap for peak concurrency including nested builds, then leave headroom rather than tuning at the point of failure.

Related Errors

• there might not be enough IDs available in the namespace — subuid/subgid exhaustion, a distinct resource from the namespace count; see Podman error: insufficient UIDs in user namespace.
• newuidmap: write to uid_map failed — the setuid helper is missing or not installed correctly; see Podman error: newuidmap exit status 1.
• cannot clone: Operation not permitted — unprivileged namespaces disabled by seccomp, AppArmor, or the unprivileged_userns_clone gate.
• netavark: IO error — network setup failing after the namespace is created, a later stage of the same startup path; see Podman error: netavark IO error.

Frequently Asked Questions

Why does the error mention “Too many open files”? The kernel returns ENOSPC for an exhausted namespace quota, and the runtime’s error formatting can print a mismatched strerror string before the parenthetical explanation. Trust the max user namespaces exceeded text and check /proc/sys/user/max_user_namespaces rather than raising your file-descriptor limit.

Is raising the sysctl a security risk? User namespaces are the mechanism rootless containers depend on, so a nonzero limit is a prerequisite, not a weakening of your posture. The historical concern is that they widen the kernel attack surface for unprivileged users; if your threat model requires that restriction, run rootful Podman under a controlled service account instead of disabling the feature and expecting rootless to work.

How many namespaces does one container use? At least one for the container itself, plus additional namespaces for pods and any nested engines. Budget generously rather than computing exactly — a few tens of thousands costs nothing and removes an entire class of intermittent CI failure.

Why does the limit reset after reboot? sysctl -w only changes the running kernel. Without a file under /etc/sysctl.d/ the value reverts to the kernel or distro default at boot, and a later drop-in with a higher-numbered filename can override yours. Grep /etc/sysctl.d/ and /usr/lib/sysctl.d/ to confirm which file wins. For more container-runtime fixes, see the Podman guides.