Cannot run flatpaks in a Fedora container

I use the official Fedora container images to build a flatpak app. However, I notice that starting in Fedora 36, flatpak run no longer works. Does anyone else notice this problem? Should I file a bug report? I’m not sure if this qualifies as a Fedora-centric issue or if the bug report should go directly upstream with flatpak. I guess that’s why I’m checking here first.

I tried searching to see if any other similar issues were reported, but, not finding any, I dug into things. This is a minimal example to run inside a container:

dnf install -y flatpak
flatpak remote-add --if-not-exists flathub
flatpak install -y flathub org.freedesktop.Platform//21.08
flatpak run org.freedesktop.Platform

If successful, it changes the prompt to [📦 org.freedesktop.Platform /]#.

Using podman run --privileged --rm -it, everything works as expected. (The --privileged option addresses this error during flatpak run: bwrap: Creating new namespace failed: Operation not permitted.)

However, for both and, they fail with this error message:

error: Could not connect: No such file or directory

Using strace I tracked where the error originated to this system call, when it attempts to connect to the dbus system bus:

connect(13, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110) = -1 ENOENT (No such file or directory)

Inside the containers, dbus isn’t running, so it makes sense that this would fail. I eventually traced down the call to this line inside check_parental_controls(). Note that if malcontent support is enabled at compile-time it hits this line, otherwise check_parental_controls() is always successful.

So why does flatpak work in Fedora 35 but not in Fedora 36? They both have the same version of flatpak:

$ flatpak --version
Flatpak 1.12.7

However, I found that Fedora builds flatpak with malcontent support starting in Fedora 36 but it is not applied to Fedora 35.

I don’t know what is the “right” thing to do here. Should dbus run in a container after all? Flatpak seems to handle the lack of dbus just fine except for this parental control check. Should this parental control case be made more robust so that a missing dbus connection is not a total failure? Or some option added to flatpak run to override the parental control check?

As an update, starting a dbus session within the container works:

dnf install -y dbus-daemon
mkdir /run/dbus
dbus-daemon --system
flatpak run ...
1 Like