Distrobox and Toolbox both give you a mutable Linux shell inside a rootless Podman container, with your home and the host network wired in. You can install Distrobox and Toolbox on Fedora in one dnf command, and both work on a healthy Podman 6 install, because they run on the host network and never needed slirp4netns. The real difference is the images. Toolbox wants images built for it, while Distrobox takes almost any registry image and prepares it on first use.
Below, we build an Ubuntu 26.04 box with Distrobox, export its binaries to the host, create Fedora and Ubuntu toolboxes and fix the errors we hit. Every command below was run on Fedora 45 with Podman 6.1 and on Fedora 44 with Podman 5.8 in October 2026, and the outputs are copied from those two VMs.
Pick Distrobox or Toolbox
Install both if you have the disk, because they do not conflict and each one wins a different job. Toolbox is the better choice when you want a clean Fedora sandbox for compilers and libraries, since its images arrive ready and the first command came back in under 5 seconds on our hosts. Distrobox is the one to reach for when you need a distro Toolbox cannot build, or when you want an app from the container to show up on the host like a native one. Here is how they split on the hosts we tested:
- Toolbox: Arch Linux, Fedora, RHEL and Ubuntu through
--distro - Distrobox: most distro images on Docker Hub, Quay and other registries, Debian included
- Exporting apps and binaries to the host: Distrobox only
- Image size: 2.27 GB for the Fedora toolbox image, 113 MB for the plain
ubuntu:26.04image Distrobox used
The size gap is misleading on its own, because Distrobox downloads the missing packages into the container on first enter, so the small image grows once you use it. Our Distrobox vs Toolbx benchmark measures that growth, the cold and warm start times and the integration flags side by side. For running services rather than living in a shell, plain rootless Podman with Quadlet is the better tool.
Install Distrobox and Toolbox on Fedora
Both packages live in the main Fedora repository, and Podman is already on Workstation and the Cloud images. Naming it in the same transaction costs nothing and covers minimal installs where it is missing.
sudo dnf install -y distrobox toolbox podmanOn Fedora 45 the transaction installed six packages, the two tools plus flatpak-session-helper, hicolor-icon-theme and the weak dependencies skopeo and p11-kit-server, for 39 MiB on disk. Confirm what landed.
rpm -q distrobox toolbox podmanFedora 45 ships the same Distrobox and Toolbox releases as Fedora 44, so only the Podman line differs between the two hosts:
distrobox-1.8.2.5-2.fc45.noarch
toolbox-0.3-7.fc45.x86_64
podman-6.1.4-1.fc45.x86_64The Fedora 44 host returned the older Podman major with rebuilt packages of the same two tools:
distrobox-1.8.2.5-1.fc44toolbox-0.3-4.fc44podman-5.8.9-1.fc44
Neither tool runs a daemon. Distrobox is a set of shell scripts and Toolbox is a Go binary, and both hand the real work to rootless Podman under your own account. So there is no group to join and no service to enable.
Check the Podman 6 backend on Fedora 45
Podman 6 dropped slirp4netns in favour of pasta, cgroups v1, the BoltDB database and iptables support (nftables only now). That matters for a host you upgraded from an older release, so check what your Podman reports before you blame Distrobox for a broken container:
podman info --format "{{.Host.NetworkBackend}} {{.Host.CgroupsVersion}} {{.Host.DatabaseBackend}} rootless={{.Host.Security.Rootless}}"Both fresh hosts printed the same line, which is what you want to see:
netavark v2 sqlite rootless=trueIf yours says boltdb or v1, usually on a host carried over from an older release, fix Podman first with the Podman upgrade repair steps, because every container Distrobox or Toolbox creates goes through that storage. Neither tool needs slirp4netns itself. The containers below all ran on the host network, and slirp4netns was not even installed on either VM.
Only passt is installed for rootless networking, which is the default Podman uses for any container that does not share the host network.
Create an Ubuntu container with Distrobox
Distrobox works with the plain images on Docker Hub, so an Ubuntu 26.04 box needs nothing but the image name and a container name you will type often. Run it as your normal user, never with sudo, or the container ends up in root’s storage where your session cannot see it:
distrobox create --image docker.io/library/ubuntu:26.04 --name ubuntu26 --yesThe create step only pulls the image and defines the container, which took 25 seconds on both hosts. The slow part is the first enter, when Distrobox’s init script installs the packages it needs for host integration and sets up your user inside the container:
distrobox enter ubuntu26Every init step prints a status line, and the package install is the one that takes the time:
Starting container... [ OK ]
Installing basic packages... [ OK ]
Setting up devpts mounts... [ OK ]
Setting up read-only mounts... [ OK ]
Setting up read-write mounts... [ OK ]
Setting up host's sockets integration... [ OK ]
Integrating host's themes, icons, fonts... [ OK ]
Setting up distrobox profile... [ OK ]
Setting up sudo... [ OK ]
Setting up user's group list... [ OK ]
Setting up existing user - shell... [ OK ]
Setting up existing user - groups... [ OK ]
Ensuring user's access... [ OK ]
Container Setup Complete!That first enter took 11 minutes 22 seconds on Fedora 45 and 12 minutes on Fedora 44, almost all of it apt downloading packages from the Ubuntu mirror. An Arch container on the same Fedora 45 host finished its first enter in 46 seconds, so the wait depends on the distro’s mirror, not on Podman. Do the first enter before you need the box, then later enters take about 2 seconds.
Work inside the Distrobox container
Inside, you are the same user with the same home directory, and Ubuntu’s own package manager handles everything you install. A file written on the Fedora side is readable from Ubuntu straight away, because /home/josphat is bind mounted rather than copied. Write a test file on the host, then read it from the container without entering a shell:
echo "written on the host" > ~/from-host.txt
distrobox enter ubuntu26 -- cat ~/from-host.txtThe text comes back unchanged, which confirms the shared home:
written on the hostPackages installed with apt stay inside the container and never touch the Fedora RPM database. Install two small tools that the next section exports, refreshing the package lists first:
distrobox enter ubuntu26 -- bash -c "sudo apt-get update -qq && sudo apt-get install -y -qq jq htop"The container’s sudo asks for no password, because Distrobox set it up for your user during init. The box also shares the host’s network and process namespace and runs privileged with SELinux labelling turned off:
podman inspect ubuntu26 --format "net={{.HostConfig.NetworkMode}} pid={{.HostConfig.PidMode}} privileged={{.HostConfig.Privileged}} label={{.HostConfig.SecurityOpt}}"The same flags came back on both Fedora releases:
net=host pid=host privileged=true label=[label=disable apparmor=unconfined unmask=all]That is a convenience boundary, not a security one. Anything you run in the container can read your SSH keys and talk to every port the host can, so do not use Distrobox or Toolbox to try untrusted software. A normal podman run without those flags is the right place for that.
Export apps and binaries to the Fedora host
distrobox-export writes a small wrapper on the host that enters the container and runs the program there, so you can call it without thinking about the container. Run it from inside the container, here through enter --, and point binaries at ~/.local/bin, which Fedora already puts on your PATH:
distrobox enter ubuntu26 -- distrobox-export --bin /usr/bin/jq --export-path ~/.local/binApps with a desktop file export with --app, which drops a launcher into ~/.local/share/applications:
distrobox enter ubuntu26 -- distrobox-export --app htopDistrobox confirms each export and names the launcher after the container, so the menu shows Htop (on ubuntu26):
Application htop successfully exported.
OK!
htop will appear in your applications list in a few seconds.Watch the name clash on the binary side. The Fedora 45 host already had jq-1.8.2 from the Fedora repo, yet after the export type jq pointed at the wrapper and jq --version printed the Ubuntu build, because ~/.local/bin comes before /usr/bin in the path:
Pick a different export name or path when a tool exists on both sides, or you will end up debugging the wrong version. The wrapper itself is plain shell, so cat ~/.local/bin/jq shows exactly which container and binary it calls. Remove an export with the same command plus --delete:
distrobox enter ubuntu26 -- distrobox-export --bin /usr/bin/jq --export-path ~/.local/bin --delete
distrobox enter ubuntu26 -- distrobox-export --app htop --deleteYour current shell may keep the old path cached after the delete (ours printed jq is hashed), so run hash -r or open a new terminal before checking.
Create a Fedora toolbox
With no options, Toolbox pulls registry.fedoraproject.org/fedora-toolbox tagged with your host’s release and names the container after it. The pull is the bulk of the time, 1 minute 35 seconds for the 2.27 GB Fedora 45 image:
toolbox create -yToolbox prints the container name it picked.
Created container: fedora-toolbox-45
Enter with: toolbox enterGet an interactive shell with toolbox enter, or run one command and come straight back with toolbox run. Because the image is built for Toolbox, the first command came back in 2.9 seconds and later ones in 1.2:
toolbox run grep -E "^(PRETTY_NAME|VERSION_ID)=" /etc/os-releaseThe container reports the same release as the host.
VERSION_ID=45
PRETTY_NAME="Fedora Linux 45 (Toolbx Container Image)"This is where Toolbox earns its place. Install a compiler toolchain inside, and the host stays exactly as it was, which is the whole workflow on Silverblue and Kinoite where the host cannot take dnf packages at all:
toolbox run sudo dnf install -y jq gcc makeInside the toolbox, gcc --version reported GCC 16.2.1 on both releases. On the host, rpm -q gcc still answered package gcc is not installed, so nothing leaked out. On Fedora 44 the same commands produced fedora-toolbox-44 and a 2.2 GB image.
Run other Fedora releases and distros
Toolbox builds containers for an older Fedora with --release, and for another distro with --distro, which needs --release too unless the distro matches the host. Both of these worked on the Fedora 45 host:
toolbox create -y --release 44
toolbox create -y --distro ubuntu --release 24.04Both add a matching flag to toolbox run and toolbox enter, so you never have to remember the generated container names. The Ubuntu one comes from quay.io/toolbx:
toolbox run --distro ubuntu --release 24.04 grep PRETTY_NAME /etc/os-releaseIt answers with the current 24.04 point release.
PRETTY_NAME="Ubuntu 24.04.5 LTS"Anything outside Toolbox’s short list goes to Distrobox. We tried Debian with Toolbox first and got a flat refusal, shown in the troubleshooting section, and Arch went through Distrobox with the official image:
distrobox create --image docker.io/library/archlinux:latest --name arch --yes
distrobox enter arch -- grep PRETTY_NAME /etc/os-releaseThe seven containers we built on the two hosts compare like this. Create time includes the image pull, and the last column is the first command after create, which for Distrobox includes its init.
| Host | Container | Tool | Image size | Create | First command |
|---|---|---|---|---|---|
| Fedora 45 | fedora-toolbox-45 | Toolbox | 2.27 GB | 1m 35s | 2.9 s |
| Fedora 45 | fedora-toolbox-44 | Toolbox | 2.2 GB | 46 s | not timed |
| Fedora 45 | ubuntu-toolbox-24.04 | Toolbox | 1.04 GB | 49 s | not timed |
| Fedora 45 | ubuntu26 | Distrobox | 113 MB | 25 s | 11m 22s |
| Fedora 45 | arch | Distrobox | 411 MB | 32 s | 46 s |
| Fedora 44 | fedora-toolbox-44 | Toolbox | 2.2 GB | 1m 31s | 4.5 s |
| Fedora 44 | ubuntu26 | Distrobox | 113 MB | 25 s | 12m 0s |
Toolbox pays its cost up front in a large pull and then starts instantly, while Distrobox pulls little and pays on first enter, by an amount that depends on the distro mirror. Once a container exists, both tools enter it in 1 to 2 seconds, so pick by the distro you need and whether you want exports, not by speed. Everything on one screen from the Fedora 45 host:
All three toolboxes run side by side under the same user, and the Debian error at the bottom is the reason Debian and its derivatives belong in Distrobox.
Remove containers and reclaim disk
Our Fedora 45 host held 6 GB of images and 1.9 GB of container layers by the end of the tests, so clean up boxes you no longer use. Each tool removes its own containers, and distrobox rm also deletes the exported wrappers and launchers that pointed at the container:
distrobox stop arch --yes
distrobox rm arch --force
distrobox rm ubuntu26 --force
toolbox rm --all --forceImages stay behind after the containers go. Prune the unused ones, then check that Podman’s storage is empty.
podman image prune -af
podman system dfAfter the prune, both hosts reported zero images and zero containers:
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 0 0 0B 0B (0%)
Containers 0 0 0B 0B (0%)
Local Volumes 0 0 0B 0B (0%)podman image prune -af removes every image no container uses, including ones you pulled for other work, so on a shared machine remove the images by name with podman rmi instead.
Fix Distrobox and Toolbox errors
These four came up during the Fedora 45 and Fedora 44 runs. None of them is a Podman 6 regression, but two of them look like one at first glance.
distrobox list prints a broken table with label text
With the official ubuntu:26.04 image, distrobox list printed the right first row and then a long line of org.opencontainers.image labels and mount paths in the ID column, on both Podman 6 and Podman 5. The cause is Canonical’s image description label, which spans several lines, and distrobox list parses podman ps output one line at a time. The containers themselves are fine. Distrobox labels every container it creates, so filter on that label for a clean list:
podman ps -a --filter label=manager=distrobox --format "{{.Names}} {{.Image}} {{.Status}}"The same filter with label=com.github.containers.toolbox=true lists only toolboxes.
Error: can’t evaluate field Slirp4NetNS in type *define.HostInfo
Podman 6 removed the Slirp4NetNS field from podman info, so any script or alias that formats it fails on Fedora 45 with exit code 125, while the same template prints an empty value on Fedora 44. Ask for {{.Host.Pasta.Executable}} instead, which returned /usr/bin/pasta on both releases. Distrobox and Toolbox do not read that field, so this only breaks your own tooling.
Error: invalid argument for ‘–distro’
toolbox create --distro debian stops with that error and a second line, Distribution debian is unsupported., because Toolbox only knows the distros it has images for. Use Distrobox with docker.io/library/debian:stable, or pass a compatible custom image to Toolbox with --image.
Container shows Exited (143) after you log out
Between two SSH sessions, ubuntu26 went from running to Exited (143) 5 minutes ago, and the next enter ran the Distrobox init again, quickly this time because the packages were already there. Rootless containers belong to your user session, and with Linger=no, the default on both hosts, systemd stops them when your last session ends. On a desktop that never matters. On a server where you want a box to survive logouts, run loginctl enable-linger $USER once.
Our default on a Fedora workstation is a Fedora toolbox for build dependencies and one Distrobox per foreign distro you actually need, with exports only for tools you do not already have on the host. For multi-container stacks, move to Podman Compose; for software that only ships for Docker, the Docker CE install on Fedora covers it, and the rest of the post-install checklist is in things to do after installing Fedora 45. Upstream options for both tools are documented in the Distrobox docs and on containertoolbx.org.
