You need a specific version of a GUI tool
You need Inkscape 1.2 for a client project, but Fedora 40 ships 1.3 and the client's pipeline breaks with the new version. Or you need a specific Python environment with GUI tools that conflicts with the system packages. You don't want to install snap or flatpak just for this, and you definitely don't want to break your host system by downgrading packages. You spin up a container, install the app, and now you have a terminal window running a GUI app inside a container. That works, but clicking through a terminal to launch a drawing tool every time is tedious. You want the app in your application menu. You want it to feel native.
How container display sharing works
Containers isolate the filesystem and processes, but they share the display server by default on Fedora. Toolbox and Distrobox mount the host's $XDG_RUNTIME_DIR into the container. This gives the container access to the Wayland or X11 socket. When you run a GUI app inside, it draws directly to your host display. The container doesn't have its own screen. It borrows yours.
Exporting an app creates a bridge. For GUI apps, Distrobox generates a .desktop file on the host that points to a wrapper script. That script enters the container and runs the binary. For CLI tools, it creates a symlink or wrapper in your PATH. The host sees a normal application. The execution happens inside the container. The wrapper handles the context switch transparently.
Distrobox uses Podman by default on Fedora. Podman runs rootless. You don't need sudo for container management. This is safer than Docker and aligns with Fedora's security model.
Run a GUI app with Toolbox
Toolbox shares your home directory and display automatically. You can run a GUI app from the host terminal without entering the container first. Toolbox is lightweight and matches your host Fedora release. It does not create persistent desktop launchers for container apps. You type the command every time.
Here's how to launch a GUI app inside a toolbox from the host terminal.
toolbox run --container my-fedora-dev gedit
# --container specifies the target container if you have multiple
# gedit runs inside the container but draws on the host display
Toolbox gives you the window. It does not create a persistent launcher. You type the command every time.
Export a GUI app with Distrobox
Distrobox has a dedicated distrobox-export command. This creates persistent launchers and binary wrappers. You can use any base image, not just Fedora.
Here's how to create a container, install an app, and export it to the desktop.
distrobox create --name legacy-inkscape --image docker.io/library/ubuntu:22.04
# --name sets the container identifier for future commands
# --image pulls the base image from Docker Hub
distrobox enter legacy-inkscape
# Enter the container shell to install software
sudo apt update && sudo apt install inkscape
# Install the application inside the container environment
Once the app is installed, export it.
distrobox-export --app inkscape
# --app generates a .desktop file in ~/.local/share/applications
# The wrapper script handles container entry and execution automatically
Exit the container. Inkscape now appears in your Fedora application launcher as if it were installed natively. Clicking the icon runs the wrapper script, which enters the container and launches Inkscape.
The app appears in your menu. Clicking it launches the container wrapper transparently.
Export a binary for the terminal
You can also export CLI tools so they are callable from your host shell. This is useful for development tools or utilities you use frequently.
Here's how to export a binary to your local bin directory.
distrobox-export --bin /usr/bin/inkscape --export-path ~/.local/bin
# --bin creates a wrapper script for the specified binary path
# --export-path places the wrapper where your shell can find it
Ensure ~/.local/bin is on your PATH. Most Fedora shells include this by default, but verify if the command isn't found.
echo $PATH | grep -q ~/.local/bin || export PATH="$HOME/.local/bin:$PATH"
# Verify ~/.local/bin is in PATH or add it to your shell profile
Now running inkscape from the host terminal transparently enters the container and launches the binary.
Run the binary name from any terminal. The wrapper handles the context switch.
Verify the export
A broken wrapper leaves a ghost in your application menu. Always verify the export created the correct files.
Here's how to check that the desktop entry and wrapper script exist.
ls ~/.local/share/applications/distrobox-legacy-inkscape-inkscape.desktop
# Confirm the desktop entry exists for the GUI launcher
file ~/.local/bin/inkscape
# Confirm the binary export is a script, not the actual binary
If file reports a binary format instead of a script, the export failed. Re-run the export command.
Check the wrapper script. If it's a binary file, the export failed.
Common pitfalls and errors
If the app crashes immediately with Cannot open display, the container lost access to the display socket. This happens if you started the container with --no-mount flags that strip the runtime directory, or if your session variables changed.
(inkscape:1234): Gtk-WARNING **: cannot open display:
Check that the environment variables are set correctly inside the container.
distrobox enter legacy-inkscape
echo $XDG_RUNTIME_DIR
# Should output /run/user/1000 or similar
echo $WAYLAND_DISPLAY
# Should match the host, usually wayland-0
Re-enter the container. Environment variables often reset if you use distrobox enter after a long idle period or a host reboot.
The container mounts your host home directory. If the app writes a config file inside the container, it writes to your host home. This can cause version conflicts. The host app might try to read a config written by the container app and crash. Isolate configs if the versions differ significantly. A mismatched config file can break both the host and container versions.
File dialogs might fail if xdg-desktop-portal isn't handling the portal correctly. Fedora usually handles this, but if a dialog doesn't appear, check the portal. If file dialogs are missing, restart the portal service. The container relies on the host portal for standard dialogs.
Manage updates and removal
Containers don't update with dnf upgrade. You must enter and update the container separately.
Here's how to update packages inside the container.
distrobox enter legacy-inkscape
sudo apt update && sudo apt upgrade
# Update packages inside the Ubuntu container
To remove an exported app, delete the export first.
distrobox enter legacy-inkscape
distrobox-export --app inkscape --delete
# Removes the desktop entry and wrapper script
Delete the export before removing the container. Orphaned wrappers break your menu.
Run updates inside the container. The host upgrade does not touch container filesystems.
When to use Toolbox, Distrobox, or alternatives
Use Toolbox when you need a Fedora-based environment that matches your host release and you only run apps occasionally from the terminal. Use Distrobox when you need persistent desktop launchers, binary exports, or access to non-Fedora base images like Ubuntu or Alpine. Use Flatpak when the application is available in Flathub and you want automatic updates and strict sandboxing without managing containers manually. Use a native RPM install when the package is in the Fedora repos and you don't need version isolation. Stay on the host system when the tool is a simple CLI utility that doesn't conflict with system libraries.