ValveSoftware
Desktop Mode Broken XDG Portals
Your system information
- Steam client version: 1759461205
- SteamOS version: 3.7.15
- Opted into Steam client beta?: No
- Opted into SteamOS beta?: No
- Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:
SteamOS needs to update its KDE base. In the current version, XDG portal is completely broken until restarted via the following command: systemctl --user restart xdg-desktop-portal.service
Relevant report: https://forums.opensuse.org/t/latest-update-has-borked-the-xdg-portals-used-by-firefox-and-chrome/185010
Due to this issue, the following are the most obvious behaviors that can occur:
- HTML redirects within other flatpak applications (ex. GitHub) fail to open the browser
- Browsers are unable to call applications from within itself, such as to unzip a file after download
Strangely enough, Mod Organizer 2 running under Proton is able to call Firefox via its in-app redirects. However, the flip-side isn't possible when invoking nxm (Nexus Mods) download links from Firefox to MO2. As per the above, this behavior is only resolved by restarting xdg-desktop-portal.service.
Steps for reproducing this issue:
- Download any zip file via Firefox
- Try to open zip file via Firefox's Download pane
- Observe issue "Do you want to open file using System Handler?"
I am not able to reproduce the issue you're describing on a Steam Deck where I flashed 3.7.15. The installed version of xdg-desktop-portal is 1.18.4-2, the version of xdg-desktop-portal-kde is 6.2.5-1.
In the desktop session, I can see both the GTK and KDE portal backend processes running, and opening a downloaded file from firefox (flatpak) does the right thing (i.e. for a compressed archive it opens it in Ark by default, whereas for a txt file I'm prompted through the KDE app chooser to select an app between Kate, KWrite, Okular and Vim).
How is a 5 months old post about updates in OpenSUSE Tumbleweed relevant to SteamOS ?
@Nuascura could it be that you are running Plasma as a Nested Desktop inside the gaming session? If so, your issue is #2063, and that OpenSUSE forum post is indeed irrelevant.
@oSoMoN No, I'm not running in nested desktop mode. If you're able to help me properly diagnose my issue, I'd be glad to receive help.
I'm confused on why you would pose the question "How is a 5 months old post about updates in OpenSUSE Tumbleweed relevant to SteamOS ?" even if as a genuine and productive ask. The plasma shell 6.2.5 is far outdated at this point, having been released on Dec 31, 2024. Further, the command lines noted in that 5 month old post helped resolve my issue per desktop session restart. So yes, I'm confused how your question contributes to resolving my issue, even if only limited to my end.
That was a genuine question. OpenSUSE Tumbleweed and SteamOS are two completely different OSes, built and updated very differently, hence my remark.
Let's try to get to the bottom of the problem you're seeing. Can you reliably reproduce everytime you switch to the desktop session?
If so, can you share the output of the following commands before restarting the service?
$ systemctl status --user xdg-desktop-portal
$ journalctl -b | grep xdg-desktop-portal
I understand your concern, but that doesn't cover why the command line I quoted helps solve my issue per session - hence why, even though there are two OSs here, the correlation is what I'm pointing out.
To be clear, I've never had this issue until around a week ago. I've reflashed my Steam Deck several times and updated across SteamOS versions through general use without issue. I feel like this issue was introduced to my end after updating to SteamOS 3.7.15, but I can't tell what else I've done differently.
I've pasted the output for the first command you wrote, confirming that my issue is present in my desktop session before doing so. There was no output for the second command.
● xdg-desktop-portal.service - Portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
Active: active (running) since Wed 2025-10-15 01:14:31 CST; 4min 2s ago
Invocation: 90685c8882964c3ab9083c9d9922a6fd
Main PID: 2811 (xdg-desktop-por)
Tasks: 6 (limit: 17661)
Memory: 2.5M (peak: 3.2M)
CPU: 87ms
CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/xdg-desktop-portal.service
└─2811 /usr/lib/xdg-desktop-portal
Oct 15 01:14:30 Steam-Deck systemd[1429]: Starting Portal service...
Oct 15 01:14:31 Steam-Deck xdg-desktop-por[2811]: No skeleton to export
Oct 15 01:14:31 Steam-Deck systemd[1429]: Started Portal service.
Something I want to also clarify:
HTML links from within Steam's desktop app call Firefox (my default browser) without any issues. On the other hand, links within the Discord flatpak don't redirect properly. So it is definitely something limited to how flatpaks are behaving on my end - inability to call between flatpak apps and out of flatpaks (ex. from firefox to Ark). Redirection into flatpaks are no issue.
Ok, we're gonna need to enable verbose logging for xdg-desktop-portal to try to understand what's going on. Can you do the following?
$ systemctl edit --user xdg-desktop-portal
and paste the following lines in the editor that's open, then save and exit:
[Service]
ExecStart=
ExecStart=/usr/lib/xdg-desktop-portal -v
then run:
$ systemctl --user daemon-reload
then reboot the device and switch to desktop mode, and finally share the output of the following command:
$ journalctl --user --no-pager -b -u xdg-desktop-portal.service
Dear @oSoMoN , please see below for output.
Konsole vim saved via :wq, and before entering commands, I confirm the issue persists each session via html redirects in Discord.
Oct 15 17:01:03 Steam-Deck systemd[1542]: Starting Portal service...
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: Looking for portals configuration in 'gamescope-portals.conf'
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: Looking for portals configuration in 'portals.conf'
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: load portals from
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.MemoryMonitor
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.PowerProfileMonitor
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.NetworkMonitor
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.ProxyResolver
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.Trash
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.GameMode
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: providing portal org.freedesktop.portal.Realtime
Oct 15 17:01:03 Steam-Deck xdg-desktop-por[1995]: No skeleton to export
Oct 15 17:01:03 Steam-Deck systemd[1542]: Started Portal service.
Oct 15 17:01:03 Steam-Deck xdg-desktop-portal[1995]: XDP: org.freedesktop.portal.Desktop acquired
Oct 15 17:01:04 Steam-Deck xdg-desktop-portal[1995]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:04 Steam-Deck xdg-desktop-portal[1995]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:07 Steam-Deck xdg-desktop-portal[1995]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:24 Steam-Deck systemd[1542]: Stopping Portal service...
Oct 15 17:01:24 Steam-Deck systemd[1542]: Stopped Portal service.
Oct 15 17:01:27 Steam-Deck systemd[1542]: Starting Portal service...
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: Looking for portals configuration in 'gamescope-portals.conf'
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: Looking for portals configuration in 'portals.conf'
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: load portals from
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.MemoryMonitor
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.PowerProfileMonitor
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.NetworkMonitor
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.ProxyResolver
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.Trash
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.GameMode
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: providing portal org.freedesktop.portal.Realtime
Oct 15 17:01:27 Steam-Deck xdg-desktop-por[2912]: No skeleton to export
Oct 15 17:01:27 Steam-Deck systemd[1542]: Started Portal service.
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: org.freedesktop.portal.Desktop acquired
Oct 15 17:01:27 Steam-Deck xdg-desktop-portal[2912]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:41 Steam-Deck xdg-desktop-portal[2912]: XDP: Assigning app ID "steam" to pid 3736 which has unit "[email protected]"
Oct 15 17:01:41 Steam-Deck xdg-desktop-portal[2912]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:41 Steam-Deck xdg-desktop-portal[2912]: XDP: No 'realtime' permissions found: No entry for realtime
Oct 15 17:01:42 Steam-Deck xdg-desktop-portal[2912]: XDP: No 'realtime' permissions found: No entry for realtime
The second half of the log, where presumably you switched to desktop mode, looks suspicious for two reasons:
- "load portals from" without a valid directory name suggests that the value of the
$XDG_DESKTOP_PORTAL_DIRenvironment variable is an empty string, but it should have been unset when plasma starts - the mention of "gamescope-portals.conf" suggests the current desktop isn't properly detected as KDE
Can you share the output of the following command when in a desktop session?
$ systemctl --user show-environment | grep -e "XDG.*DESKTOP"
@CaptainKthulhu may have made an astute observation in their post. @oSoMoN it may be that XDG portal / desktop service only breaks when booted-into with an external display connected. This observation potentially introduces additional variables to consider.
I'm using the Steam Deck dock with an Asus VY229HE display.
I disconnected my display, keeping the dock connected and powered via my outlet. Booted desktop mode on the internal display, and XDG desktop service worked a-okay. Shutdown Deck, connected HDMI to external display, booted into desktop mode, and the subject issue did not re-appear.
For records sake, the earliest I can find of this issue online is 3 years ago via this Reddit post: https://www.reddit.com/r/SteamDeck/comments/xmvenn/workaround_for_links_not_working_in_flatpak/
I can no longer replicate my issue. If I'm able to surface the issue again, I'll provide an output to that command.
Good find! I can now observe the issue if I boot my Steam Deck with an external monitor connected via HDMI to the dock. Looking into what might cause this.
Bug resurfaced. If it helps at all, this is the output for the last requested command input:
$ systemctl --user show-environment | grep -e "XDG.*DESKTOP"
XDG_CURRENT_DESKTOP=KDE
XDG_SESSION_DESKTOP=$'KDE (One-Time Launch)'
I'm sure you've seen that by now on your own Deck. I re-checked this output after restarting desktop service and there was no difference in content.
Right, the problem isn't with the environment itself, it appears to be a timing issue: when the xdg-desktop-portal service is restarted, it detects that it's still running under a gamescope session:
$ strings /proc/$(pidof xdg-desktop-portal)/environ | grep -e "XDG.*DESKTOP"
XDG_CURRENT_DESKTOP=gamescope
XDG_DESKTOP_PORTAL_DIR=
XDG_SESSION_DESKTOP=gamescope
To be compared with the output of the same command when no external monitor is connected:
$ strings /proc/$(pidof xdg-desktop-portal)/environ | grep -e "XDG.*DESKTOP"
XDG_CURRENT_DESKTOP=KDE
XDG_SESSION_DESKTOP=KDE (One-Time Launch)
When the external monitor is connected doesn't appear to matter: I booted my device into the default gamescope session with no external monitor, then connected one and switched to desktop, and the problem is there.
This observation of a timing issue is confirmed by the fact that the value of $XDG_CURRENT_DESKTOP is set to "KDE" by /usr/bin/startplasma-x11 (see setupPlasmaEnvironment()), which itself is invoked by /usr/lib/sddm/sddm-helper-start-x11user, and when an external monitor is connected I consistently see that process started with a PID greater than that of the /usr/lib/xdg-desktop-portal process.
I have tested applying locally https://github.com/flatpak/xdg-desktop-portal/commit/4d284de29d1d0740c9b80b634631a8f253287680, but as a result xdg-desktop-portal isn't being restarted when switching sessions, so it doesn't improve things.
Filed https://github.com/flatpak/xdg-desktop-portal/issues/1835 to look for a generic solution.
Filed flatpak/xdg-desktop-portal#1835 to look for a generic solution.
Hey. Any update on this by any chance?
Anything I can do or try to help?
I'm investigating. It appears that when switching from gamescope to desktop, graphical-session.target isn't activated, whereas it works in the other direction (desktop -> gamescope). As a result xdg-desktop-portal.service isn't restarted.
Just wanted to chip in saying that I'm facing the exact issues as OP, and their workaround fixed my issue!
systemctl --user restart xdg-desktop-portal.service
Only after doing this, Firefox is able to open up links with the system handler correctly (e.g. links opening up the Steam app, etc.) and VS Code is able to open up Firefox to log into e.g. GitHub.
@irfanhakim-as To be clear, this command only solves the issue for the current desktop session. Once your device is restarted, the issue will resurface.
@oSoMoN Were you able to test this issue on other docks beside the Steam Deck Docking Station? Or did you already replicate the issue on the third-party docks?
I haven't been testing consistently, but I feel somewhat confident enough to make a small hypothesis that might be a contributing cause but may not be the prime perpetrator.
I have two docks in my possession: The Steam Deck Docking Station and the ROG Bulwark Dock (DG300). Anecdotally, I haven't seen desktop portal service bug out since I switched to the Bulwark dock.
I have a feeling there is a relation between the dock and the subject issue because I also noticed a change in behavior with Bluetooth. I am aware that the current Steam Deck OLED on SteamOS 3.8 has an issue with bluetooth devices (keyboard or mouse) waking it up. This isn't an issue by itself since we do want bluetooth devices to wake Steam Deck from sleep if said devices are moved. However, this bluetooth behavior is an issue because these devices at physical idle keep the Deck from staying consistently in sleep mode.
Where this bluetooth behavior also appears is with bluetooth dongles such as the Logi Bolt receiver. I noticed that, even if my Logitech mouse is turned off, Steam Deck would refuse to stay asleep for as long as the Logi Bolt receiver is plugged into the dock. I had to always remove the receiver to eliminate this behavior.
Where this bluetooth behavior diverges is with Logi Bolt receiver in the Bulwark dock. Even if the receiver is connected to Steam Deck through the Bulwark, Steam Deck is able to stay properly asleep.
Tl;dr: The Steam Deck Docking Station, or its relative limitations, may be interfering with the timing of xdg-desktop-portal service's restart process.
@Nuascura yea I'm aware that it's a temporary workaround, hence the italic in fixed. Also, just want to inform that this issue is happening to me on 2 different docks: the official Steam Deck Dock, and a JSAUX-branded one. My initial suspicion was that this has to do with the Steam Deck booting into Gaming Mode first before Desktop (got this idea from somewhere in this thread), and that it might not be an issue if we were to boot to Desktop first - but I'm not sure if this is possible to test.
@Nuascura I've been using a JSAUX dock for the longest time ever since I've pretty much had my Steam Deck LCD, I'm not sure if the dock is the problem if this happens with different ones aside from the official, I've reinstalled steamOS over cachyOS for steam deck since I still prefer the original. Issue seems to persist even in a fresh install after a while and always happens if you boot into desktop mode while connected to an external display, seems to not have changed since last I checked.
Also not sure if this is in any way, shape or form related to xdg-desktop-portal but most of the time, connected to an external display, booting into desktop mode not only breaks what everyone is describing but the steam deck screen becomes unusuable as a 2nd monitor because its completely black and no amount of tinkering with settings fixes it.
Also not sure if this is in any way, shape or form related to xdg-desktop-portal but most of the time, connected to an external display, booting into desktop mode not only breaks what everyone is describing but the steam deck screen becomes unusuable as a 2nd monitor because its completely black and no amount of tinkering with settings fixes it.
That's most likely a separate issue, would you mind filing it?
@Nuascura I've been using a JSAUX dock for the longest time ever since I've pretty much had my Steam Deck LCD, I'm not sure if the dock is the problem if this happens with different ones aside from the official, I've reinstalled steamOS over cachyOS for steam deck since I still prefer the original. Issue seems to persist even in a fresh install after a while and always happens if you boot into desktop mode while connected to an external display, seems to not have changed since last I checked.
Hi, I currently also use a 3P dock, the Ugreen one, and the OS was working fine before a recent update on main channel, stable. I beleive it is the OS that borked with XDG rather than the dock.
I intentionally didn't respond because I explicitly said it was just a hypothesis and could be wrong. But before more people chime in with "docks" from common manufacturers (jsaux, ugreen, anker etc.), I'm going to make two things clear:
- I said the dock could be a contributing factor, not the prime perpetrator (which is likely SteamOS from what we've seen)
- Not all "docks" are docks. Docks are already sometimes glorified USB (dongle) hubs, or colloquially interchangeable in terms of terminology. The line is at times thin. But some docks have greater power delivery capability, update-able firmware, or specific dock-specific controllers.
If you are considering adding to discussion of "docks" and less so to investigating the actual issue at heart, it would be far more productive for you to identify your specific dock model and AB test with a Steam Deck Docking Station.
Seems to fixed in main branch 20251112.1000 build
Mostly fixed, there's one remaining fix that has been merged and will be included in the next image build. All the required fixes will be backported to the upcoming 3.8 release (currently in the preview channel).
Until then, let's keep this issue open.
I am having this issue and believe my system is fully updated, is this fixed?
Same Problem here. connected with via dock to a hdmi 1440p monitor. have to portal restart to get any links in flatpaks working
