You need to install a package, but the host says no
You are working on a project and the documentation tells you to run sudo dnf install python3-dev-tools. You type the command and the package manager warns you about a conflict with a system library, or you are on Fedora Silverblue where the host filesystem is immutable and refuses the install entirely. You remember reading about containers, but the search results split into two paths: Toolbox and Distrobox. You need to know which tool fits your workflow before you start typing commands.
Both tools solve the same problem. They give you a mutable environment where you can install packages, compile code, and break things without touching your host system. The difference lies in how they manage that environment and how they integrate with your desktop. Toolbox is designed to feel like a second copy of your host. Distrobox is designed to be a flexible wrapper around any container image.
What is actually happening
Containers share the host kernel. They isolate the filesystem, processes, and network namespaces, but they run on the same operating system core. This makes them lightweight and fast compared to a full virtual machine. You do not need to allocate gigabytes of RAM or emulate hardware.
Fedora uses Podman as the container engine. Podman is daemonless and runs containers as your user by default. This is a rootless model. You do not need sudo to create or run containers. This reduces the blast radius of a mistake. If a container process goes rogue, it cannot easily compromise the root filesystem because it lacks root privileges on the host.
Toolbox and Distrobox are both clients that talk to Podman. Toolbox creates a container that mirrors the host release and user configuration. It sets up the environment so that dnf works inside the container and your home directory is mounted automatically. Distrobox creates a container from a specified image and sets up integration for GUI applications, audio, and home directory access. Distrobox allows you to run Ubuntu, Arch, or Debian inside Fedora, or run a different Fedora release than the host.
Setting up Toolbox
Toolbox is the standard choice for Fedora Workstation and Silverblue when you need a development environment that matches the host. It creates a container named fedora-toolbox by default. The container tracks the same Fedora release as your host. If you are on Fedora 40, the toolbox is Fedora 40.
Here is how to install Toolbox and create a container that mirrors your host system.
# Install the toolbox package. This pulls in podman and the toolbox client.
# Podman is the container engine. Toolbox is the management wrapper.
sudo dnf install toolbox
# Create a container named 'fedora' that matches the host release.
# The --distro flag ensures the container tracks the same Fedora version as your host.
# This command pulls the base image from the registry if it is not cached locally.
toolbox create --distro fedora
# Enter the container. Your home directory is mounted automatically.
# The prompt changes to indicate you are inside the container.
# You can run commands here without affecting the host system.
toolbox enter
Once inside, you can install packages freely. The container has its own package database. Running dnf install inside the container does not touch the host packages. Your home directory is shared, so files you create in the container are visible on the host. This is useful for projects. You can edit code in your host editor and run it inside the container.
Toolbox also provides a run command. This lets you execute a single command inside the container without entering the shell. This is useful for scripts or one-off tasks.
# Run a command inside the container without entering the shell.
# This is useful for checking versions or running build steps from the host.
# The command executes in the container's environment with the container's binaries.
toolbox run dnf install gcc make
Run dnf upgrade inside the container regularly. The host update cycle does not apply to the container. If you forget, the container drifts and might break when the host kernel updates.
Setting up Distrobox
Distrobox is the choice when you need a different distribution or fine-grained control over the container. You specify the image explicitly. Distrobox handles the integration of GUI applications, audio, and clipboard access. It also provides an export feature that lets you install binaries in the container and make them available on the host.
Here is how to install Distrobox and create a container using a specific image.
# Install distrobox. This provides the distrobox command and integration scripts.
# Distrobox uses podman by default on Fedora. No docker daemon is required.
sudo dnf install distrobox
# Create a container named 'ubuntu-dev' using the official Ubuntu image.
# The -n flag sets the name. The -i flag specifies the image to pull.
# Distrobox will pull the image from the registry if it is not cached locally.
# The image name follows the registry format: registry/repo:tag.
distrobox create -n ubuntu-dev -i docker.io/library/ubuntu:latest
# Enter the container. Distrobox sets up environment variables so GUI apps
# can display on your host desktop and access your home directory.
# The prompt changes to show the container name.
distrobox enter ubuntu-dev
Distrobox supports systemd inside the container. By default, containers use init or s6. If you need systemd services, you must enable it during creation. This is common for development tools that rely on systemd units.
# Create a container with systemd support enabled.
# The --init systemd flag tells Distrobox to run systemd as PID 1 inside the container.
# This allows you to use systemctl inside the container for managing services.
# Systemd support increases resource usage slightly but is required for some tools.
distrobox create -n fedora-systemd -i fedora:latest --init systemd
Distrobox also allows you to export binaries to the host. This lets you install a tool in the container and run it from the host terminal. This is useful for testing a package before installing it on the host.
# Export a binary from the container to the host.
# The --package flag specifies the package to install in the container.
# The --bin flag specifies the binary to export.
# Distrobox creates a wrapper script in ~/.local/bin on the host.
# You can run the binary from the host after exporting.
distrobox export --package python3-pip --bin pip3
Edit configuration files in /etc inside the container. Files in /usr/lib ship with the package and will be overwritten on update. The same rule applies inside containers as on the host.
Verifying the environment
You need to confirm you are inside the container and that the environment is set up correctly. Run cat /etc/os-release to check the distribution. Run whoami to check the user. Run ls -Z to check SELinux contexts if you are troubleshooting permissions.
# Check the OS release inside the container.
# This confirms you are running the expected distribution and version.
# The output should match the image you specified or the host release for Toolbox.
cat /etc/os-release | grep PRETTY_NAME
# Check the current user.
# Both tools map your host user into the container.
# Your UID and GID should match the host user.
whoami
# Check SELinux contexts on your home directory.
# The container mounts /home with the correct labels.
# If you see 'unconfined_u' instead of 'container_file_t', permissions may fail.
ls -Z ~/
If the output matches expectations, the container is ready. If whoami shows root, you created the container incorrectly. Both tools run as your user by default. Do not run containers as root unless you have a specific reason.
Common pitfalls and errors
Containers can fail due to socket issues, permission errors, or SELinux denials. The error messages point to the cause.
If you see Error: cannot connect to Podman socket, your user is not in the podman group or the socket is not running. Run systemctl --user start podman.socket to start the socket. Add your user to the podman group if the error persists.
Error: cannot connect to Podman socket.
Is your user in the podman group?
If you see permission denied when accessing files, check SELinux. Fedora enforces SELinux by default. Containers need the right labels. Toolbox handles this automatically. Distrobox usually does too, but if you mount custom volumes, you might need :Z or :z options.
Permission denied: /home/user/project/file.txt
If you see Failed to connect to bus: No such file or directory when running systemctl, systemd is not enabled in the container. Recreate the container with --init systemd.
Failed to connect to bus: No such file or directory
Run podman ps to see what is running. If the container isn't listed, it isn't working. Run podman logs <container> to see the startup logs. Read the actual error before guessing.
When to use Toolbox vs Distrobox
Use Toolbox when you want a development environment that feels identical to your host Fedora system.
Use Toolbox when you are on Fedora Silverblue or Kinoite and need a mutable layer for installing packages.
Use Toolbox when you want minimal configuration and automatic integration with the host user and home directory.
Use Distrobox when you need to test software against a different distribution like Ubuntu, Arch, or Debian.
Use Distrobox when you want to run a specific container image that isn't based on Fedora.
Use Distrobox when you need fine-grained control over container creation flags and volume mounts.
Use Distrobox when you want to export binaries from the container to the host.
Stay on the host when you only need standard packages available in the Fedora repositories.
Reboot the container if the network breaks. podman restart fixes most transient issues. Trust the rootless model. If you find yourself needing sudo inside the container, check the tool configuration first.