Skip to content
🎉 Launch sale:50% off everything over $22 — automatically applied at checkout· ends Aug 2Shop the sale →
DevOps AI ToolKit
Newsletter
All guides
AI for Podman By James Joyner IV · · 9 min read Last reviewed Jul 2026

Podman Error: 'failed to start slirp4netns' and Rootless Network Setup Failures

Quick answer

Fix rootless Podman networking: install slirp4netns or passt, switch default_rootless_network_cmd, tune MTU, clear stale /run/user netns, and unblock low ports.

  • #podman
  • #containers
  • #troubleshooting
  • #errors
Free toolkit

Stuck on this Podman error? Get the free incident triage checklist

A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.

Exact Error Message

$ podman run --rm -p 8080:80 docker.io/library/nginx:alpine
Error: failed to start slirp4netns process: fork/exec /usr/bin/slirp4netns: no such file or directory

With the pasta backend the same class of failure reads differently:

Error: pasta failed with exit code 1:
Couldn't open network namespace /run/user/1000/netns/netns-9b2c...: No such file or directory
Failed to set up rootless network: exit status 1

What It Means

Rootless Podman cannot create a normal bridge or veth pair, because that needs privileges an unprivileged user does not have. Instead it hands networking to a userspace helper that runs in your user namespace and forwards packets over a tap device: either slirp4netns (the long-standing default) or pasta, shipped by the passt project (the default for new rootless containers on current Podman). When Podman says it failed to start that helper, container creation stops before the network namespace is usable — so the container never runs at all, even though the image pulled fine.

The failure modes split into three groups. The helper binary is simply not installed, which is the no such file or directory case and by far the most common on minimal or container-in-container hosts. Or the helper is present but the network namespace path under /run/user/$UID/netns/ is stale — typically after a reboot, or after a session ended with systemd lingering disabled, leaving Podman’s stored state pointing at directories /run no longer has. Or the helper starts but the resulting network is broken rather than absent: MTU mismatches on VPN/overlay uplinks, unforwardable low ports, and host-loopback access that is disabled by default.

Common Causes

  • slirp4netns or passt is not installed, while containers.conf still names it as the rootless network command.
  • default_rootless_network_cmd in containers.conf is set to a backend that is not present on this host.
  • Stale /run/user/$UID/netns/ entries after a reboot, because /run is tmpfs and Podman’s state still references the old namespaces.
  • Lingering is off for the user, so systemd-logind tears down /run/user/$UID at logout and takes running container state with it.
  • MTU mismatch: the default slirp4netns MTU is larger than the usable MTU over a VPN, WireGuard, or cloud overlay, so connections hang rather than fail loudly.
  • Publishing a port below 1024 rootless, which the kernel forbids unless net.ipv4.ip_unprivileged_port_start is lowered.

Diagnostic Commands

First find out which backend Podman intends to use and whether the binaries exist:

podman info --format '{{.Host.NetworkBackend}}'
podman info --format '{{.Host.Slirp4netns.Executable}}'
which slirp4netns pasta

Check the merged containers.conf for an explicit backend selection. The user file overrides the system one:

grep -rn 'default_rootless_network_cmd\|network_backend' \
  /usr/share/containers/containers.conf \
  /etc/containers/containers.conf \
  /etc/containers/containers.conf.d/ \
  ~/.config/containers/containers.conf 2>/dev/null

Inspect the runtime directory for stale namespace files, which is the usual post-reboot culprit:

ls -l /run/user/$(id -u)/netns/ 2>/dev/null
loginctl show-user "$(id -un)" --property=Linger

Reproduce the helper directly to see its own error text rather than Podman’s wrapper:

podman run --rm --log-level=debug docker.io/library/alpine:3.19 true 2>&1 | grep -iE 'slirp|pasta|netns'

And check the low-port threshold if the failure is specifically about publishing a privileged port:

sysctl net.ipv4.ip_unprivileged_port_start

Step-by-Step Resolution

  1. Install the helper Podman is asking for. Install both if you want to be able to switch backends freely:
sudo dnf install -y slirp4netns passt      # RHEL/Fedora
sudo apt-get install -y slirp4netns passt  # Debian/Ubuntu
which slirp4netns pasta
  1. Pin the backend explicitly in your user containers.conf so the choice is not left to defaults that shift between releases:
mkdir -p ~/.config/containers
tee ~/.config/containers/containers.conf >/dev/null <<'EOF'
[network]
default_rootless_network_cmd = "slirp4netns"
EOF

Set it to "pasta" instead if you want the newer backend, which generally gives better throughput and preserves the host’s source addressing.

  1. Clear stale runtime state after a reboot or a lost session. podman system migrate recreates the namespaces and re-points stored containers at valid paths:
podman system migrate
podman ps -a
  1. Enable lingering so /run/user/$UID and any running rootless containers survive logout:
sudo loginctl enable-linger "$(id -un)"
loginctl show-user "$(id -un)" --property=Linger
  1. If containers start but network traffic stalls — DNS resolves, TLS handshakes hang — lower the MTU. This is standard on VPN and overlay uplinks:
podman run --rm --network slirp4netns:mtu=1400 docker.io/library/alpine:3.19 \
  wget -qO- https://example.com >/dev/null && echo ok

Make it permanent by adding the option to the network section of containers.conf, and use allow_host_loopback=true when the container must reach a service bound to the host’s loopback:

podman run --rm --network slirp4netns:allow_host_loopback=true \
  docker.io/library/alpine:3.19 wget -qO- http://10.0.2.2:5432
  1. To publish a port below 1024 rootless, lower the unprivileged port floor rather than reaching for sudo:
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-rootless-ports.conf
podman run --rm -d -p 80:80 docker.io/library/nginx:alpine

If the container now gets a network but dies immediately afterwards, the failure has moved to the runtime or cgroup layer — see crun sd-bus transport endpoint.

Prevention

  • Install slirp4netns and passt as part of host provisioning wherever rootless Podman runs, including CI images.
  • Pin default_rootless_network_cmd in containers.conf so a Podman upgrade cannot silently change your network path.
  • Enable loginctl enable-linger for every service account running rootless containers, before the first deploy.
  • Standardize an MTU for hosts behind VPN or overlay networks and set it once in containers.conf rather than per podman run.
  • Set net.ipv4.ip_unprivileged_port_start in /etc/sysctl.d/ rather than relying on ad hoc sysctl -w that a reboot discards.
  • Include a rootless podman run --rm alpine wget -qO- https://example.com smoke test in host validation to catch backend regressions early.
  • rootlessport cannot expose privileged port 80 — the port-forwarding handler hit the unprivileged port floor; lower ip_unprivileged_port_start.
  • netavark: unable to append rule — the netavark backend, not slirp4netns/pasta, is failing on firewall rules.
  • error tearing down network namespace — stale /run/user/$UID/netns state; run podman system migrate.
  • bind: address already in use — the published host port is taken by another process, unrelated to the rootless helper; check for a stale pod via pod already exists.

Frequently Asked Questions

Should I use slirp4netns or pasta? pasta (from the passt package) is the modern default and is generally faster, with the container appearing to use the host’s own address. slirp4netns is more widely packaged and better documented for options like mtu= and allow_host_loopback=. Pin whichever one you install everywhere.

Why does everything break after a reboot? /run/user/$UID lives on tmpfs and is recreated empty at boot, while Podman’s stored container state still references the old namespace paths. podman system migrate reconciles the two, and enable-linger prevents the equivalent problem at logout.

Why do downloads hang instead of failing? That is almost always MTU. The helper’s default MTU exceeds what the uplink can carry, so small packets like DNS succeed and larger TLS records silently stall. Test with --network slirp4netns:mtu=1400.

How does the container reach a service on the host? Rootless containers cannot see the host’s loopback by default. Use --network slirp4netns:allow_host_loopback=true and address the host as 10.0.2.2 from inside the container. For more container fixes, see the Podman guides.

Free download · 368-page PDF

Fixed it? Get 500 Podman & DevOps AI prompts — free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.

Did this fix your issue?

Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.