horizon-client: invalid locale and no font don't work well with xfce4 black theme

env GTK_THEME=Adwaita LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 horizon-client

Distrobox: failed to create task for container: failed to create shim task: OCI runtime create failed: cannot stat /usr/lib64/libEGL_nvidia.so.580.159.03: No such file or directory failed to start containers: fbox

I have distrobox container, fbox, which was created using the following command:

distrobox create -i quay.io/fedora/fedora:44-n fbox -H ~/home-fbox --additional-flags "--device=nvidia.com/gpu=all" '
It was working for a while, and now, after I upgraded my gentoo host, I can't enter fbox. I get the error:


Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: cannot stat /usr/lib64/libEGL_nvidia.so.580.159.03: No such file or directory failed to start containers: fbox
The solution was to regenerate nvidia.yaml:

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

distrobox: Opening Images in Native GIMP from IrfanView Running Under Wine in Distrobox

I use IrfanView via Wine inside a Distrobox container and wanted its external editor feature to open images directly in native GIMP. IrfanView passes the image path in Windows format (Z:\home\home-folder\Pictures\photo.jpg), so a small Python script handles the conversion and launches GIMP. Sounds simple. It wasn't.

Two things needed fixing before GIMP would even start. First, GIMP's sandboxed image loader (glycin) uses bubblewrap, which cannot create user namespaces inside a container — fixed with GLYCIN_DISABLE_SANDBOX=1. Second, any process launched from the script died the moment the script exited, because Wine kills all child processes when its own child (the Python script) returns.

Even after solving those, GIMP crashed every time it tried to open a file, with a GTK3 assertion failure inside GtkFileChooserWidget. The same command worked perfectly from the shell. The environment variables were identical. The difference turned out to be invisible to env: Wine installs a seccomp filter on its processes, and that filter is inherited by every child process across fork and exec. No amount of environment tweaking or session detachment can clear an inherited seccomp filter. GTK's file chooser widget makes a syscall during initialisation that Wine's filter blocks, and GIMP crashes.

The fix is to launch GIMP as a transient systemd user service with systemd-run --user --no-block. A process started this way is owned by systemd, not Wine — clean process state, no inherited seccomp filter, completely outside Wine's process tree.

#!/usr/bin/python
import os, sys, subprocess

def convert_wine_path(p):
    return p.replace('\\', '/').replace('Z:', '')

env = os.environ.copy()
img_file = convert_wine_path(sys.argv[1]) if len(sys.argv) == 2 else None

cmd = [
    'systemd-run', '--user', '--no-block',
    '--setenv=GLYCIN_DISABLE_SANDBOX=1',
    f'--setenv=DISPLAY={env["DISPLAY"]}',
    f'--setenv=HOME={env["HOME"]}',
    f'--setenv=XDG_RUNTIME_DIR={env["XDG_RUNTIME_DIR"]}',
    '/usr/bin/gimp'
]
if img_file:
    cmd.append(img_file)

subprocess.run(cmd)


Save it somewhere on your Linux filesystem, point IrfanView's external editor to the Z: path equivalent, and it works. The same trick applies to any native Linux app you need to launch cleanly from within Wine.

gentoo and distrobox: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started

I have gentoo host, with systemd, nvidia and docker. When I want to create a distrobox image with systemd in the container, e.g.:
distrobox create --nvidia -i archlinux -n abox -H ~/home-abox --init --additional-packages "systemd"
I was getting: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started
The solution was to use crun container runtime, instead of default runc. To do this

1. Install crun: emerge -av app-containers/crun
2. Create `/etc/docker/daemon.json` with the content: {
"runtimes": {
"crun": {
"path": "/usr/bin/crun"
}
},
"default-runtime": "crun"
}
3. Restart docker sudo systemctl restart docker

Distrobox with systemd: "save as" does not work in chromium and brave

If "save as" window does not work in chromium and brave executed in distrobox, this maybe because, container's systemd hijacked debus from the host. Thus you can disable it in the container and restart the container:
systemctl --user mask dbus.socket dbus-broker.service
systemctl --user stop dbus.socket dbus-broker.service
In my case I was using fedora 43 in the container, on gentoo host running systemd and xfce4 (x11). The XDG portal (xdg-desktop-portal-gtk) on host was installed and running.

distrobox: firefox "Show in Folder" opens vscodium, not thunar or other file manager.

Run in distrobox (make sure thunar is installed in distrobox first):

xdg-mime default thunar.desktop inode/directory
xdg-mime default thunar.desktop x-scheme-handler/file

distrobox: firefox does not open file chooser windows

If you run Firefox inside a Distrobox container on a Gentoo (or any) Linux host, you may notice that the "Save Page As" dialog simply never appears. You hit Ctrl+S, nothing happens. No window, no error, just silence.

The culprit is XDG Desktop Portals. Firefox tries to detect whether it's running inside a sandboxed environment like Flatpak, and when it thinks it is, it hands off file chooser dialogs to the XDG portal service instead of opening a native GTK window. Distrobox leaks enough container-like environment variables to trigger this heuristic, so Firefox dutifully tries to call the portal over D-Bus — but the portal either isn't reachable from inside the container or isn't running at all. The call fails silently and you never see a dialog.

The fix is a single preference change in about:config:
widget.use-xdg-desktop-portal.file-picker = 0
Setting this to 0 tells Firefox to never use the portal for the file picker, falling back to the plain GTK file chooser. The dialog comes back immediately, no restart required.

The default value of 2 means "auto-detect", which is the right call for a real Flatpak sandbox where portals are properly set up. In a Distrobox environment though, the detection fires incorrectly and there's no graceful fallback. Until Distrobox masks the relevant environment variables or Firefox improves its detection logic, flipping this preference manually is the most reliable workaround.

distrobox with nvidia through NVIDIA Container Toolkit

First setup NVIDIA Container Toolkit and docker support for it based on your host's distrubution. Then you can: distrobox create -i archlinux -n abox -H ~/home-abox --additional-flags "--device=nvidia.com/gpu=all" && distrobox enter abox -- bash -c "sudo pacman -Sy --noconfirm git base-devel && git clone https://aur.archlinux.org/yay-bin.git /tmp/yay-bin && cd /tmp/yay-bin && makepkg -si --noconfirm && rm -rf /tmp/yay-bin"

nixos: enable nvidia in distrobox container using Nvidia Container Toolkit

What worked for me on nixos with docker (check nixos wiki on Nvidia and Nvidia Container Toolkit) was:

distrobox create -i archlinux -n archbox --additional-flags "--device=nvidia.com/gpu=all"
Then in the distrobox container you can check if nvidia is detected, using for example glxinfo. It should show: name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
Put the following in nixos configuration file: hardware.nvidia-container-toolkit.enable = true;
virtualisation.docker.daemon.settings.features.cdi = true;

gentoo with xfce4: krusader does not start from distrobox

kf.i18n: KLocalizedString: Domain is not set for this string, translation will not work. Please see https://api.kde.org/frameworks/ki18n/html/prg_guide.html msgid: "No jobs" msgid_plural: "" msgctxt: ""

Authorization required, but no authorization protocol specified

10:26:41.584-warning qt.qpa.xcb unknown@0 # could not connect to display :0.0 10:26:41.584-warning qt.qpa.plugin unknown@0 # From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin. 10:26:41.584-info qt.qpa.plugin unknown@0 # Could not load the Qt platform plugin "xcb" in "" even though it was found. 10:26:41.584-fatal default unknown@0 # This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, wayland-brcm, wayland-egl, wayland, vkkhrdisplay, vnc, offscreen, xcb, minimalegl, eglfs, minimal.
install xhost in gentoo host: sudo emerge x11-apps/xhost
and allow access to display: xhost +
now can enter the fedora distrobox

distrobox: create archlinux container with automatic yay installation

distrobox create -i archlinux -n abox -H ~/home-abox && distrobox enter abox -- bash -c "sudo pacman -Sy --noconfirm git base-devel && git clone https://aur.archlinux.org/yay-bin.git /tmp/yay-bin && cd /tmp/yay-bin && makepkg -si --noconfirm && rm -rf /tmp/yay-bin"

Fixing KDE App Theming in Distrobox on XFCE

If you run a KDE application (like Krusader) inside a Distrobox container on an XFCE host with a dark theme, you might notice that the icons are dark and nearly invisible against the dark background. This happens because the app inherits a mismatched icon theme from the host, and no Qt platform theme manager is configured inside the container.

The Fix

First, enter your container and install the required packages:

distrobox enter abox
sudo pacman -S papirus-icon-theme qt6ct


Note: check whether your KDE app links against Qt5 or Qt6 before choosing between qt5ct and qt6ct:

ldd $(which krusader) | grep -i qt


Next, tell Qt to use qt6ct as the platform theme. In fish shell, set it as a universal variable so it persists across sessions:

set -Ux QT_QPA_PLATFORMTHEME qt6ct


Then configure the theme and icons by editing the qt6ct config directly:

mkdir -p ~/.config/qt6ct
cat > ~/.config/qt6ct/qt6ct.conf << 'EOF'
[Appearance]
icon_theme=Papirus-Dark
style=Breeze
EOF


Finally, set up kdeglobals so KDE apps pick up the correct color scheme and icon theme:

cat > ~/.config/kdeglobals << 'EOF'
[General]
ColorScheme=BreezeDark

[KDE]
widgetStyle=Breeze

[Icons]
Theme=Papirus-Dark
EOF


Open a fresh container session and launch your KDE app — the icons and theme should now render correctly.

distrobox: export Notepad++ installed thorugh wine

distrobox-export --app Notepad++

void linux with docker: distrobox hangs when a container with --init and systemd is created.

Distrobox lets you run any Linux distribution as a container and integrate it into your host system. But if your host is Void Linux, getting a systemd-based box like Arch to boot correctly takes a bit of extra work.

The problem

Void uses runit as its init system, not systemd. When you create a distrobox with --init and ask for a systemd container, it will hang forever printing:

waiting for systemd to come up...
waiting for systemd to come up...
waiting for systemd to come up...

Even after fixing the cgroup setup (which also requires attention on a non-systemd host), systemd inside the container will fail on several units that try to mount kernel filesystems — things like binfmt_misc, hugepages, and sys-kernel-debug. These units make no sense inside a container and will block the boot sequence.

The fix

The solution is to mask those units at creation time, before systemd ever tries to start them. The --init-hooks flag runs a shell command during container setup, so we can pre-create the /dev/null symlinks that systemctl mask would normally create:

distrobox create -i archlinux -n abox -H ~/home-abox --init --additional-packages "systemd" --additional-flags "--privileged" --init-hooks "mkdir -p /etc/systemd/system && for u in proc-sys-fs-binfmt_misc.automount proc-sys-fs-binfmt_misc.mount sys-kernel-debug.mount sys-kernel-tracing.mount dev-hugepages.mount systemd-firstboot.service systemd-udevd.service; do ln -sf /dev/null /etc/systemd/system/\$u; done"

The --privileged flag gives systemd the capabilities it needs to manage its own cgroup namespace. The hook symlinks all the container-hostile units to /dev/null, which is exactly what masking does — just without needing systemctl to be running yet.

Why symlinks instead of systemctl? At hook execution time systemd hasn't started yet, so systemctl mask may not work reliably. Writing symlinks directly achieves the same result and works unconditionally.

Result

After running this command, distrobox enter abox will boot straight through into a fully working Arch Linux shell with a live systemd instance — on a Void Linux host running runit.

Posted March 2026

Void Linux: "/" is not a shared mount, this could cause issues or missing mounts with rootless containers

When running distrobox with podman:
"/" is not a shared mount, this could cause issues or missing mounts with rootless containers Just add mount --make-rshared / to your /etc/rc.local

Void Linux, podman and distrobox: unable to apply cgroup configuration

Error: unable to start container "0a58490ca8d4b9cf464483b8a776e53616ebfc60cc89aa25e60b0d910d907eb2": runc: runc create failed: unable to start container process: unable to apply cgroup configuration: rootless needs no limits + no cgrouppath when no permission is granted for cgroups: mkdir /sys/fs/cgroup/0a58490ca8d4b9cf464483b8a776e53616ebfc60cc89aa25e60b0d910d907eb2: permission denied: OCI permission denied
Create ~/.config/containers/containers.conf: [containers]
cgroupns = "host"


[engine]
cgroup_manager = "cgroupfs"
runtime = "crun"

sudo xbps-install -S crun

Remove the container, and install it again, e.g.: distrobox stop abox
distrobox rm abox
podman system reset
distrobox create -i archlinux -n abox -H ~/home-abox
distrobox-enter abox


Void Linux: podman and distrobox: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.con

Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
Edit: /etc/containers/registries.conf and add:

unqualified-search-registries = ["docker.io"]

Fix: Firefox in Distrobox "Show in Folder" Opens the Wrong App on Linux

In Distrobox, install thunar if using xfce4 and add inode/directory=thunar.desktop into ~/.config/mimeapps.list: [Default Applications]
inode/directory=thunar.desktop

Start libreoffice in dark theme from distrobox on nix os through .desktop file

On Host, after exporting the libreoffice from distrobox, edit e.g. ~/.local/share/applications/abox-libreoffice-calc.desktop and add "env GTK_THEME=Adwaita:dark": Exec=env GTK_THEME=Adwaita:dark /run/current-system/sw/bin/distrobox-enter -n abox -- libreoffice --writer %U

NixOS: Libreoffice in distrobox does not use Adwaita dark theme

GTK_THEME=Adwaita:dark libreoffic
or set in fish config:
set -x GTK_THEME Adwaita:dark