Can't open links from flatpak applications


I’m running Fedora 39 (XFCE) and am having trouble opening links from flatpak applications. When I click on a link, nothing happens. If I run the app with --log-session-bus, I see this message logged

Failed to call portal: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface ?org.freedesktop.portal.OpenURI? on object at path /org/freedesktop/portal/desktop

Doing some googling about this, I found that I need to install xdg-desktop-portal, but it seems that it was already installed for me

$ rpm -qa |grep portal

What else can I try? I’m not really familiar enough with flatpak internals to know where to look.

This is what I’ve taken to calling the portalpocalypse. xdg-desktop-portal 1.18 has dropped the fallback that would use the first available backend, so if your desktop environment doesn’t have one of the new portal configuration files, you get nothing.

XFCE upstream has added one, but it needs to be backported into the Fedora package. Please file a bug against xfce4-session in Fedora.

For now, you can create it yourself: ~/.config/xdg-desktop-portal/xfce-portals.conf:


x-d-p-gtk implements all the most essential portals, but it’s probably also worth installing xdg-desktop-portal-xapp.

Thanks for the insight!

Is there something I need to do beyond just put that file there? It doesn’t seem to be taking effect; I get the same output in the session bus log

[~/.config/xdg-desktop-portal] nick@scooty-puff-jr$ cat xfce-portals.conf 

My system also has this package

Well, you need to restart xdg-desktop-portal (or your session).

Try /usr/libexec/xdg-desktop-portal -rv. If it still doesn’t work with that running, please share the output.

aha, so it does work if I run it with this command, but after a reboot it doesn’t work on its own.

From that command:

XDP: Default handler firefox for https, x-scheme-handler/https
XDP: Recommended handlers for https, x-scheme-handler/https: chromium-browser, firefox
XDP: Can skip app chooser for x-scheme-handler/https
XDP: Found in permission store: handler: (null), count: 0 / 3, always ask: 0
XDP: Allowing to skip app chooser: can use default
XDP: Skipping app chooser
XDP: Launching firefox [link]

This is perhaps a silly question, but what normally runs this? I see that the xdg-desktop-portal rpm includes a systemd service, but even after making sure that was running, links didn’t work

[~] nick@scooty-puff-jr$ rpm -ql xdg-desktop-portal-1.18.1-1.fc39.x86_64  |grep systemd

That is only used in GNOME. /usr/share/xdg-desktop-portal/gnome-portals.conf looks like this:


In earlier versions of x-d-p, it would be used over x-d-p-gtk purely due to alphabetical sorting, which wasn’t ideal.

Ok, yes I am using gnome on workstation.

It’s a D-Bus session service that is autostarted on first access: /usr/share/dbus-1/services/org.freedesktop.portal.Desktop.service. That file contains SystemdService=xdg-desktop-portal.service, which defers to the systemd user manager if available.

This works well on GNOME, but I’m not sure what populates systemd’s environment on XFCE (e.g. DISPLAY).

What does systemctl --user status xdg-desktop-portal.service say?

Nothing useful

● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
    Drop-In: /usr/lib/systemd/user/service.d
     Active: active (running) since Fri 2023-11-10 22:18:57 EST; 1min 14s ago
   Main PID: 6323 (xdg-desktop-por)
      Tasks: 6 (limit: 37440)
     Memory: 3.7M
        CPU: 281ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-desktop-portal.service
             └─6323 /usr/libexec/xdg-desktop-portal

Nov 10 22:18:57 scooty-puff-jr systemd[1842]: Starting xdg-desktop-portal.service - Portal service...
Nov 10 22:18:57 scooty-puff-jr systemd[1842]: Started xdg-desktop-portal.service - Portal service.

One interesting thing worth noting is that links do work if I rename xfce-portals.conf to portals.conf. From man 5 portals.conf

       Users can override those defaults, or provide configuration for an otherwise unsupported desktop envi‐
       ronment, by writing a file ˜/.config/xdg-desktop-portal/portals.conf. Users of more than  one  desktop
       environment can use desktop-specific filenames such as kde-portals.conf which will only be used in the
       appropriate desktop environment.

I wonder if somehow it’s not being informed of my desktop environment properly…?

Double-posting here, but an interesting note; I checked the source code for x-d-p and it looks like the desktop environment it chooses is based on XDG_CURRENT_DESKTOP. If I check env, this is indeed XFCE (which explains why everything worked when I ran the command by hand). I wonder if in the environment it is executing, this is not set…

Yeah, this is the second report I’ve had of xfce-portals.conf not working, so I’ve been poking around in a VM.

The issue is indeed that systemd isn’t getting XDG_CURRENT_DESKTOP in its environment (systemctl --user show-environment).

Fascinating. Shouldn’t my login manager normally set that…? Well, I’m glad it works, but I’ll file a bug report for this tomorrow (first time for everything, haha).

Thank you for your help!

This part has been fixed upstream:

That will also need to be backported in Fedora for the portals file to work.

Fortunately, it looks like the x-d-p developers are coming around on restoring the fallback to -gtk, so this should hopefully become less urgent soon.

1 Like

Bug filed. Thanks for your help @chrisawi