🦭 Podman Error: 'netavark: IO error: No such file or directory' on Rootless Network Setup

Exact Error Message

$ podman run --rm -it docker.io/library/alpine:latest ip addr
Error: netavark: IO error: No such file or directory (os error 2)

The same failure often surfaces while starting an existing container or a Quadlet-managed unit:

Error: unable to start container "a1b2c3d4e5f6": netavark: IO error:
No such file or directory (os error 2): OCI runtime error

What It Means

netavark is the network stack Podman shells out to whenever a container joins a network. Podman itself does not program bridges, veth pairs, or firewall rules — it writes a JSON network configuration to netavark’s stdin and executes the netavark binary, which does the actual work inside a network namespace. aardvark-dns is the companion process netavark starts to answer container-name DNS queries on bridge networks. When Podman reports netavark: IO error: No such file or directory, the netavark process ran but could not open a path it expected to exist. That is an error bubbled up verbatim from netavark’s Rust I/O layer, not from Podman’s Go code, which is why it carries no useful context about which file was missing.

In rootless mode there are three families of paths that commonly go missing. First, the rootless network namespace state directory under $XDG_RUNTIME_DIR/netns and $XDG_RUNTIME_DIR/containers/networks — this is tmpfs-backed and evaporates on reboot or when the user’s session is torn down, while Podman’s persistent database in ~/.local/share/containers/storage still believes those namespaces exist. Second, the netavark or aardvark-dns binary itself, usually at /usr/libexec/podman/netavark and /usr/libexec/podman/aardvark-dns; if the netavark package was removed or only partially upgraded, Podman’s helper_binaries_dir lookup finds nothing. Third, a network definition in ~/.config/containers/networks/*.json that references a bridge or config file left behind by the older CNI stack. Any of these produces the same terse message.

Common Causes

• Stale rootless network state under $XDG_RUNTIME_DIR after a reboot, while the container database still references the old namespaces.
• The netavark or aardvark-dns package is missing, or was replaced during a distribution upgrade that left the helper binaries directory empty.
• network_backend in containers.conf is set to cni (or was migrated to netavark) but the on-disk network definitions belong to the other backend.
• A leftover CNI config in ~/.config/cni/net.d/ or /etc/cni/net.d/ conflicting with netavark’s ~/.config/containers/networks/.
• $XDG_RUNTIME_DIR is unset or points at a directory that no longer exists — common in cron, ssh non-login shells, and CI runners.
• A custom network was deleted or hand-edited, leaving a container attached to a network whose JSON file is gone.

Diagnostic Commands

Confirm which network backend Podman has actually selected and where it looks for helper binaries:

podman info --format '{{.Host.NetworkBackend}}'
podman info --format '{{.Host.NetworkBackendInfo}}'

Verify the helper binaries exist and are executable:

ls -l /usr/libexec/podman/netavark /usr/libexec/podman/aardvark-dns
/usr/libexec/podman/netavark --version

List the networks Podman knows about and inspect the one your container uses:

podman network ls
podman network inspect podman

Check that the rootless runtime directory is present and sane:

echo "$XDG_RUNTIME_DIR"
ls -la "$XDG_RUNTIME_DIR/containers" "$XDG_RUNTIME_DIR/netns" 2>&1

Look for orphaned CNI configuration that should no longer be in play:

ls -la ~/.config/cni/net.d/ /etc/cni/net.d/ 2>&1
ls -la ~/.config/containers/networks/

Step-by-Step Resolution

1. Reinstall or install the network helper packages. On Fedora/RHEL family systems both ship separately from podman:

sudo dnf install -y netavark aardvark-dns
# Debian/Ubuntu
sudo apt-get install -y netavark aardvark-dns

2. Clear the stale rootless network state. This is the single most effective fix after a reboot or upgrade — it tears down the user’s namespaces and lets Podman rebuild them:

podman network reload --all
podman system migrate

3. If containers still fail, stop everything for that user and drop the transient runtime state explicitly:

podman stop --all
podman system service --time=0 &>/dev/null; true
rm -rf "$XDG_RUNTIME_DIR/libpod" "$XDG_RUNTIME_DIR/netns"

4. Pin the network backend so Podman cannot flip between netavark and the legacy CNI stack. Rootless users can set this per-user in ~/.config/containers/containers.conf, or system-wide in /etc/containers/containers.conf:

[network]
network_backend = "netavark"
default_network = "podman"
helper_binary_dir = ["/usr/libexec/podman"]

5. Remove leftover CNI configuration and recreate any custom networks under netavark. Back up first — deleting a network detaches containers from it:

podman network inspect mynet > ~/mynet-backup.json
podman network rm mynet
podman network create mynet

6. As a last resort, reset the user’s entire Podman state. This destroys all containers, pods, images, volumes, and networks for that user, so export anything you need first:

podman volume export mydata --output ~/mydata.tar
podman system reset

Ensure $XDG_RUNTIME_DIR is exported correctly in non-interactive contexts before retrying, since a missing runtime directory reproduces this error immediately. If your automation reaches Podman over the API socket instead of the CLI, see Podman error: unable to connect to Podman socket for the matching socket and linger setup.

Prevention

• Keep podman, netavark, and aardvark-dns upgraded together; never pin one and float the others.
• Set network_backend explicitly in containers.conf so upgrades cannot silently change the stack under you.
• Enable loginctl enable-linger for service accounts so their $XDG_RUNTIME_DIR survives logout and reboot.
• Define custom networks declaratively (Quadlet .network units or a setup script) so they can be recreated after a reset.
• Add a podman network reload --all step to your post-reboot automation for rootless hosts.
• Purge ~/.config/cni/net.d/ once you have fully migrated to netavark, so no stale config can be picked up.

Related Errors

• netavark: unable to append rule ... to table nat — netavark ran fine but the host firewall backend rejected the rule; a firewalld/nftables problem, not a missing file.
• aardvark-dns: failed to bind udp listener on 10.88.0.1:53 — DNS helper port conflict on the bridge, distinct from a missing binary.
• Error: unable to start container: no such network — the network definition was deleted; recreate it rather than resetting.
• Error: cannot listen on the TCP port: bind: permission denied — an unrelated rootless port restriction, covered in Podman error: rootless bind to privileged port.

Frequently Asked Questions

Why does this only happen after a reboot? The rootless network namespaces live under $XDG_RUNTIME_DIR, which is a tmpfs wiped at boot, while Podman’s container database is persistent in your home directory. The database still points at namespaces that no longer exist, so netavark tries to open a path that is gone. podman network reload --all reconciles the two.

Do I have to run podman system reset? Almost never. Reset destroys every container, image, volume, and network for that user. Try reinstalling the helper packages, reloading networks, and clearing $XDG_RUNTIME_DIR/libpod first — those resolve the large majority of cases.

Is netavark required, or can I go back to CNI? Netavark is the current default and the actively developed backend; the CNI plugins path is legacy. You can set network_backend = "cni" if you still have the plugins installed, but the sustainable fix is to install netavark and aardvark-dns and migrate your network definitions.

Why does the error appear in cron or CI but not in my shell? Non-login and non-session contexts frequently have no $XDG_RUNTIME_DIR, so netavark has nowhere to place its state. Export it explicitly (export XDG_RUNTIME_DIR=/run/user/$(id -u)) and enable lingering for the account. For more rootless container fixes, see the Podman guides.