🦭 Podman Error: 'crun: sd-bus call: Transport endpoint is not connected' in Rootless Containers

Exact Error Message

$ podman run --rm docker.io/library/alpine:latest echo hi
Error: OCI runtime error: crun: sd-bus call: Transport endpoint is not connected

Depending on the crun version and how the session died, you may instead see:

Error: OCI runtime error: crun: error creating systemd scope: sd-bus call:
Transport endpoint is not connected
ERRO[0000] Removing container ... : container ... : no such container

What It Means

When rootless Podman uses the systemd cgroup manager (the default on cgroups v2 hosts), it does not write cgroup files itself. Instead the OCI runtime — crun or runc — asks your systemd user manager (user@$(id -u).service) over D-Bus to create a transient scope unit for the container, so systemd can delegate a cgroup subtree that your unprivileged user is allowed to write to. That D-Bus conversation happens on the user session bus, normally the socket at /run/user/$(id -u)/bus.

Transport endpoint is not connected is the errno ENOTCONN bubbling up from that socket connect/call. It means crun found something to talk to — an address in DBUS_SESSION_BUS_ADDRESS, or the conventional path under XDG_RUNTIME_DIR — but nothing is listening on the other end, or the session it belonged to has been torn down. In practice the user’s systemd session either never started (SSH command execution, cron, a CI runner, a su - shell inheriting a stale environment) or was reaped when your last login session closed while background containers were still expected to run.

Common Causes

• Linger is disabled, so user@UID.service and its bus are torn down the moment your last login session ends.
• The command runs from cron, a CI agent, or ssh host podman ... where no PAM session and therefore no user bus is created.
• You switched users with su - or sudo -u, which does not create a login session but does leave XDG_RUNTIME_DIR/DBUS_SESSION_BUS_ADDRESS pointing at the original user’s runtime dir.
• XDG_RUNTIME_DIR is unset entirely, so Podman falls back to a path with no bus socket in it.
• DBUS_SESSION_BUS_ADDRESS is exported but stale — it names a socket that was deleted when the previous session exited.
• dbus-user-session (Debian/Ubuntu) or dbus-daemon/dbus-broker user units are not installed, so no per-user bus is ever started.

Diagnostic Commands

First confirm whether your user actually has a running systemd manager and a bus socket:

id -u
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
echo "DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS"
ls -l /run/user/$(id -u)/bus
systemctl --user is-active default.target

Check whether linger is enabled for the account — this is the single most common cause on servers:

loginctl show-user "$USER" --property=Linger
loginctl list-users

Ask Podman what it thinks its cgroup and runtime configuration is:

podman info --format '{{.Host.CgroupManager}} {{.Host.CgroupVersion}} {{.Host.OCIRuntime.Name}}'
podman info --format '{{.Host.RemoteSocket.Path}}'

Reproduce the D-Bus failure directly, without Podman in the picture:

systemctl --user status
busctl --user list | head

If busctl --user fails the same way, the problem is your session, not Podman. Finally, run with debug logging to see the exact call crun made:

podman --log-level=debug run --rm docker.io/library/alpine:latest true 2>&1 | grep -iE "sd-bus|scope|cgroup"

Step-by-Step Resolution

1. Enable linger so the user manager and its bus start at boot and survive logout. This is the correct fix for servers running long-lived rootless containers:

sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" --property=Linger

2. Export a correct XDG_RUNTIME_DIR in non-login contexts such as cron jobs and CI scripts, and drop any inherited stale bus address:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
podman info --format '{{.Host.CgroupManager}}'

3. Stop using su - to reach the container user. Use machinectl shell, which creates a real login session with its own bus, instead:

sudo machinectl shell appuser@ /bin/bash
# inside the new session:
loginctl session-status

4. If you must run one-off commands from a session-less context, wrap them so systemd creates the scope for you:

systemd-run --user --scope --quiet podman run --rm docker.io/library/alpine:latest echo hi

5. Install the per-user D-Bus session package if /run/user/UID/bus never appears. On Debian/Ubuntu:

sudo apt-get install -y dbus-user-session
sudo systemctl restart systemd-logind

6. As a last-resort workaround where no user session can exist, tell Podman to manage cgroups itself. Do this knowingly — see the caveats below:

podman --cgroup-manager=cgroupfs run --rm docker.io/library/alpine:latest echo hi

To make it permanent for the user, set it in ~/.config/containers/containers.conf:

[engine]
cgroup_manager = "cgroupfs"

The downside is real: with cgroupfs in rootless mode you lose systemd’s cgroup delegation, so resource limits (--memory, --cpus) are frequently ignored, podman generate systemd/Quadlet units behave inconsistently, and cgroups can be left behind when containers die abruptly. Prefer fixing the session with linger. If Podman then complains that limits are being ignored entirely, the host is probably still on the old hierarchy — see cgroups v1 not supported.

Prevention

• Run loginctl enable-linger as part of host provisioning for every account that owns rootless containers.
• Manage long-lived containers with Quadlet or systemctl --user units rather than ad-hoc podman run from scripts.
• Never use su - for container users in automation; use machinectl shell or a dedicated systemd unit.
• Explicitly set XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS at the top of any cron or CI script that calls Podman.
• Keep dbus-user-session (or the distro equivalent) in your base image/host package set.
• Add a smoke check — busctl --user list >/dev/null — to CI so a broken session fails loudly instead of mid-pipeline.

Related Errors

• cannot re-exec process — the user namespace could not be set up at all, usually a subuid/subgid problem rather than D-Bus. See cannot re-exec process.
• Resource limits are not supported and ignored on cgroups V1 rootless systems — a warning, not a failure; the host lacks the unified hierarchy.
• failed to connect to user bus: No such file or directory — the socket path does not exist at all, versus existing but dead.
• slirp4netns failed — rootless networking setup failure, a separate stage of container startup. See slirp4netns failed.

Frequently Asked Questions

Why does it work when I SSH in interactively but fail from cron? An interactive SSH login creates a PAM session, which starts user@UID.service and the bus. Cron does not. Enabling linger makes the user manager exist independently of logins, which fixes both cases.

Is --cgroup-manager=cgroupfs safe for production? It will get containers running, but rootless cgroupfs cannot reliably enforce memory or CPU limits and interacts poorly with systemd-managed containers. Treat it as a stopgap on hosts where you genuinely cannot enable a user session.

I enabled linger and it still fails. Check that DBUS_SESSION_BUS_ADDRESS is not inherited from another user — a stale value from su - overrides the correct default. Unset it and let Podman derive the path from XDG_RUNTIME_DIR.

Does running as root avoid this? Yes; rootful Podman talks to the system bus, which is always present. But you lose the isolation benefits of rootless mode. For more rootless fixes see the Podman guides.