You need Ubuntu tools on a Fedora system
You installed a proprietary application that only ships an .deb package. Or a colleague handed you a script that assumes pacman is available. You are on Fedora. You could try to build from source, chase dependencies, or risk breaking your host system with third-party repositories. There is a safer path. Run the other distro inside a container that feels native. Distrobox gives you a full Ubuntu, Arch, or Debian environment with access to your home directory, display server, and sound, all without touching the host kernel or package database.
What is actually happening
Distrobox sits on top of Podman. It creates a container but bridges the gap between isolation and integration. Unlike a virtual machine, it shares the host kernel and uses minimal overhead. Unlike a standard container, it mounts your home directory and forwards X11 or Wayland sockets so GUI apps appear on your desktop. Think of it as a portable Linux distribution you can slide into your Fedora session. The container has its own root filesystem and package manager. Your host stays clean. If the container breaks, you delete it and recreate it. The host never knows.
Fedora Workstation uses Podman as the default container runtime. Podman runs rootless by default, meaning containers execute as your user without a background daemon. Distrobox orchestrates the Podman commands and adds the integration layer for your home directory, display, and audio.
Trust the container boundary. Your host packages remain untouched.
Install Distrobox
Fedora packages Distrobox in the default repositories. Podman is included in the base system on Workstation, but installing it explicitly ensures the correct version.
sudo dnf install distrobox podman
# Podman provides the container runtime. Distrobox manages the user experience and integration.
No daemon is needed. Podman runs rootless by default. The distrobox command handles all lifecycle operations.
Install the tools before you create the environment.
Create a container
Use distrobox create to pull a base image and set up the container. The --name flag assigns a label you will use for all future commands. The --image flag specifies the operating system and version.
# Ubuntu LTS
distrobox create --name ubuntu-box --image ubuntu:24.04
# --name assigns a human-readable identifier for the container.
# --image pulls the base OS image from the registry.
# Arch Linux
distrobox create --name arch-box --image archlinux:latest
# Arch uses rolling releases. The latest tag tracks the current snapshot.
# Debian Stable
distrobox create --name debian-box --image debian:bookworm
# Debian tags use codenames. Bookworm is the current stable release.
# List all containers
distrobox list
# Shows container names, images, and status.
Distrobox pulls the image from the registry on first use. Subsequent creates use the cached image. The container starts in a stopped state after creation.
Create the container with a descriptive name. You will type that name every time you enter.
Enter and use a container
Use distrobox enter to attach your terminal to the container shell. Once inside, you have a full environment with the native package manager of the base image.
distrobox enter ubuntu-box
# Attaches your terminal to the container shell.
# Your home directory is mounted automatically.
Inside the container, run commands as you would on a native install. Use sudo inside the container for administrative tasks. The sudo inside the container is isolated from the host.
# Inside the ubuntu-box
sudo apt update && sudo apt install build-essential
# Use the native package manager of the container OS.
# apt works in Ubuntu/Debian. pacman works in Arch.
# Exit back to Fedora
exit
# Closes the shell and returns to the host terminal.
Your ~/ directory is shared between the host and the container. Files you create in the container appear on the host and vice versa. The /usr/ and /etc/ directories are separate. The container has its own system libraries and configuration.
Use the container's package manager. Never run dnf inside an Ubuntu container.
Export applications to the host
Distrobox can export GUI applications and CLI tools from the container so they appear in your Fedora application menu or PATH. This is useful for tools you use frequently but want to keep isolated.
# Inside the container
distrobox-export --app firefox
# Generates a .desktop file in the host application menu.
# The wrapper script launches firefox inside the container.
# Export a binary to the host
distrobox-export --bin /usr/bin/some-tool --export-path ~/.local/bin
# Creates a wrapper script so the binary is available on the host PATH.
# --export-path specifies where the wrapper is placed.
Exported apps run inside the container but appear on the host desktop. They share your home directory and display server. The host sees the app as a normal application.
Export apps you use frequently. Keep heavy tools inside the container to avoid cluttering the host.
Run a one-off command
Use distrobox run to execute a command inside the container without opening a shell. This is useful for scripts, quick checks, or automation.
distrobox run --name ubuntu-box -- apt list --installed
# Executes a command inside the container without opening a shell.
# -- passes the command to the container shell.
The command runs in the container environment. Output is printed to your host terminal. The container starts, runs the command, and stops automatically if it was not already running.
Use run for automation. Use enter for interactive work.
Stop and remove containers
Containers consume disk space and registry bandwidth. Manage them actively.
# Stop a running container
distrobox stop ubuntu-box
# Stops the container process. State is preserved.
# Remove a container
distrobox rm ubuntu-box
# Removes the container filesystem. Data in your home directory remains on the host.
Removing a container deletes the container's root filesystem. Files in your ~/ directory are preserved because they belong to the host. Only the container-specific files in /usr/ and /etc/ are deleted.
Remove containers you no longer need. They consume disk space and registry bandwidth.
Advanced: Systemd and init systems
Some tools require systemd to manage services. Distrobox supports running systemd inside the container using --init systemd. This enables full service management but adds complexity.
distrobox create --name systemd-box --image fedora:40 --init systemd
# Enables systemd inside the container for services.
# Requires systemd-nspawn capabilities.
Systemd inside a container shares the host kernel but runs a separate init process. You can use systemctl inside the container to manage services. This is useful for development environments that rely on systemd units.
Enable systemd only when the software requires it. It adds complexity and resource usage.
Common pitfalls and errors
Distrobox handles most integration automatically. Issues usually stem from display protocols, permissions, or conflicting tools.
If a GUI app crashes immediately, check the display protocol. Fedora Workstation uses Wayland by default. Most containers handle this automatically, but legacy apps may need XWayland. If you see Cannot open display, verify the WAYLAND_DISPLAY environment variable is exported. You can force XWayland by setting DBX_XWAYLAND=1 before entering.
# Force XWayland if Wayland fails
DBX_XWAYLAND=1 distrobox enter ubuntu-box
# Overrides the display protocol for this session.
If you see Error: unable to start container: ... permission denied, the container may be in a bad state. Run distrobox stop first. If the error persists, check the container logs.
podman logs ubuntu-box
# Container logs do not go to the host journal.
# Use podman logs to debug startup issues.
Never install host packages inside the container. Running dnf inside an Ubuntu container will fail or corrupt the environment. Always use the native package manager.
Check the error message before guessing. Most failures are display or permission issues, not Distrobox bugs.
When to use Distrobox
Use Distrobox when you need a different Linux distribution like Ubuntu or Arch on your Fedora host. Use Toolbox when you need a Fedora development environment that matches the host release or a specific Fedora version. Use a Virtual Machine when you need a different kernel version or full hardware isolation for security testing. Use native packages when the software is available in the Fedora repositories and you do not need isolation. Stay on the host when you are installing system-wide services that must integrate with systemd.