I just spent two hours with Gemini 2.5 Pro Preview working on this and we thought we had it solved. I won’t bore you with the details, but somehow the latest update does two things:
-
It borks Kwallet, causing it to prompt for the user password on every reboot, as well as logging me out of all my accounts, so I have to log in to them every time in the browsers. Kwallet also crashes unexpectedly. Both of these problems are now KDE bug reports as mentioned elsewhere in these forums.
-
The Firefox and Chrome browsers now use the GTK portal instead of the KDE portal, even though ALL the relevant config files and service definitions show that they should be using the KDE XDG portal.
What appears to happen is that the KDE portal service does not run on startup and thus defaults back to the GTK portal.
For the latter situation, I can execute these commands and recover the situation:
systemctl --user start plasma-xdg-desktop-portal-kde.service
systemctl --user restart xdg-desktop-portal.service
However, the situation recurs on reboot.
Gemini suggested these possible causes:
Regarding how this might have happened on openSUSE Tumbleweed:
Tumbleweed, being a rolling release, experiences frequent updates, including major components like KDE Plasma and its associated packages. Here are a few plausible scenarios that could lead to the KDE portal service not starting automatically, even if installed:
- Package Update Transition/Renaming:
- There might have been a transition where the service file was renamed (e.g., from an older
xdg-desktop-portal-kde.serviceto the newerplasma-xdg-desktop-portal-kde.serviceduring the Plasma 5 to Plasma 6 upgrade or a subsequent Plasma 6 point release). - During such a transition, the old service might have been disabled/removed, but the new one might not have been automatically enabled or started correctly by the package update scripts. Sometimes, systemd user services require a
systemctl --user daemon-reloadand potentially a session restart (or even a full reboot) for the system to fully recognize and manage new or renamed services.
- Systemd User Service Masking or State:
- It’s possible (though less common for user services like this) that the service was inadvertently masked (
systemctl --user mask plasma-xdg-desktop-portal-kde.service) at some point, which would prevent it from starting. You can check withsystemctl --user is-enabled plasma-xdg-desktop-portal-kde.service. If it says “masked”, you’d need to unmask it. - The service might simply have failed to start on a previous boot/login due to a transient issue, and systemd didn’t automatically retry it, or its dependencies weren’t met at the exact moment it tried to start.
- Incomplete or Interrupted Update:
- If a system update (
zypper dup) that includedxdg-desktop-portal-kde6or related KDE/systemd components was interrupted or didn’t complete fully, it could leave things in an inconsistent state.
- Race Condition or Dependency Issues at Startup:
- Systemd starts services in parallel based on dependencies. It’s possible (though less likely for well-packaged services) that
plasma-xdg-desktop-portal-kde.servicetried to start before one of its own dependencies was fully ready during your user session startup, causing it to fail silently or not attempt to start again. - The main
xdg-desktop-portal.serviceitself might start and, not seeing the KDE backend immediately available (because it hadn’t started yet), defaults to GTK for the session.
- Changes in D-Bus Activation:
- The primary way these portal backends are often started is via D-Bus activation. When an application makes a portal request, D-Bus sees the request for a specific interface (e.g.,
org.freedesktop.impl.portal.desktop.kde) and then starts the service defined in the corresponding D-Bus service file (/usr/share/dbus-1/services/org.freedesktop.impl.portal.desktop.kde.service). If there was a hiccup in D-Bus configuration or if the systemd service it’s supposed to activate wasn’t found by its expected name, it wouldn’t start.
- User Configuration Overrides (Less Likely in this case):
- While we didn’t find any problematic user-specific
portals.conffiles, in some scenarios, incorrect user configs could interfere, but this seems unlikely here given the service itself wasn’t running.
Thank God for Gemini, which discovered the solution with my help. I never would have figured it out on my own. At least I can continue to function by simply executing those commands on every reboot, which means I’m functional until the next system update or other reboot.
I’m surprised no one else has reported this. If it is specific to my system, I’ll have to do a reinstall which is a major PITA. I do have an external image backup I can reinstall and then just freeze the system from updating, but that’s hardly a solution.
I’ve also noted in the last few days since the previous update that the Preview Panel in the KDE portal in the browsers can not be opened either by the Preview button or F11. That was a problem back in 2024 and it was apparently a Firefox issue. Now it affects Chrome, too. A KDE bug report back then referred the problem to Mozilla, but KDE have now reopened that bug since it affects Chrome, too. I don’t know if that relates to the current issue with the portals, possibly it doesn’t.
