Latest Update Has Borked the XDG Portals Used by Firefox and Chrome

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:

  1. 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.

  2. 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:

  1. 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.service to the newer plasma-xdg-desktop-portal-kde.service during 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-reload and potentially a session restart (or even a full reboot) for the system to fully recognize and manage new or renamed services.
  1. 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 with systemctl --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.
  1. Incomplete or Interrupted Update:
  • If a system update (zypper dup) that included xdg-desktop-portal-kde6 or related KDE/systemd components was interrupted or didn’t complete fully, it could leave things in an inconsistent state.
  1. 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.service tried 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.service itself might start and, not seeing the KDE backend immediately available (because it hadn’t started yet), defaults to GTK for the session.
  1. 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.
  1. User Configuration Overrides (Less Likely in this case):
  • While we didn’t find any problematic user-specific portals.conf files, 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.

6 Likes

OK, after much more work with Gemini, I managed to find an actual fix for this situation, as follows:

  1. sudo mkdir -p /etc/xdg-desktop-portal #Make a directory in /etc to hold a new system wide config file “portals.conf”
  2. sudo nano /etc/xdg-desktop-portal/portals.conf #Edit the file as follows:
  3. cat portals.conf
    [preferred]
    default=kde
  4. Reboot the system.

Now the KDE portal is definitely run instead of the GTK portal.

Kwallet is still crashing, however. That is a separate issue which I presume will have to fixed upstream.

Why this nonsense is happening on my system I have no idea. But I have spent the entire day working on it.

1 Like

By the way, the exact same issue occurred on my other Beelink system. Fixed it with the same fix.

So it’s not specific to my main system.

1 Like

I was working on the kwallet problem, but my kwallet does finally start running on it’s own. It also crashes again and shows up in Crashed Process Viewer…but runs again.

I use Vivaldi browser. I logged into my guest account to see what everything looked like there. Kwallet crashed there too, but started running on its own.

But…I opened Vivaldi in the guest account. When I went back to my main account, Vivaldi was locked with a key store error.

"Vivaldi could not unlock your secure key store.
Etc...etc...etc...
Do you really want to continue, but lose data?"

I had a backup of my passwords so I just continued (lost passwords & cookies etc) and imported the passwords. I don’t know if that’s just a Vivaldi problem or related to Kwallet, but I thought I’d warn people.

Back up your passwords if you still can, especially if you’re poking around looking at this problem. I never changed anything to test because it’s really hard to pin down the cause. Kwallet errors with “no display”, and I don’t know if it actually requires a display when it first starts, or wrongly just thinks it does.

Thanks for all of your time and work. With enough clues the developers will surly come up with a solution.

You may want to check your host in more detail. Infamous Host Erlangen is upgraded to 20250513 and does not exhibit any problems with startup:

karl@erlangen:~> journalctl --user -b -u plasma-xdg-desktop-portal-kde.service
Mai 15 03:39:41 erlangen systemd[1357]: Starting Xdg Desktop Portal For KDE...
Mai 15 03:39:41 erlangen systemd[1357]: Started Xdg Desktop Portal For KDE.
karl@erlangen:~> 
Mai 15 03:39:41 erlangen systemd[1357]: Starting Portal service...
Mai 15 03:39:41 erlangen systemd[1357]: Started Portal service.
karl@erlangen:~> 

Dependencies of graphical target are:

karl@erlangen:~> systemctl --user list-dependencies graphical-session.target 
graphical-session.target
...
● ├─plasma-plasmashell.service
● ├─plasma-polkit-agent.service
● ├─plasma-powerdevil.service
● ├─plasma-xdg-desktop-portal-kde.service
● ├─plasma-xembedsniproxy.service
● ├─xdg-desktop-portal.service
● ├─xdg-document-portal.service
● ├─xdg-permission-store.service
...
karl@erlangen:~> 

No reinstalls required since converting storage to btrfs in November 2019.

❯ journalctl --user -b -u plasma-xdg-desktop-portal-kde.service
-- No entries --

:confused:

I have the same problem, actually both kwallet not unlocking automatically at logon (or rather, trying and crashing), and also links from flatpak apps not opening in Firefox anymore, which I guess is related.

EDIT: indeed for the 2nd issue, workaround provided in first post worked:

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

EDIT2: I faced race conditions in the past when using SDDM, I guess I’ll try to switch to lightDM again

EDIT3: reproducible with lightDM as well, so DM’s not at fault

Hi, the same problem here on two computers (missing KDE menues and KWallet problem).
The suggested workaround works also for me.
systemctl --user start plasma-xdg-desktop-portal-kde.service
systemctl --user restart xdg-desktop-portal.service

Best,
Michael

Ditto.

BTW there are other threads talking about the kwallet problem. I think the file dialog problem is just less reported because not every user experiences it (if they don’t use Firefox or other apps that need the xdg thing), and even if they do they may not notice it right away.

1 Like

My dependencies list is very long. No way I can figure out what’s the controlling issue.

I’m just going to assume that eventually this will be fixed. In the meantime I’ll just run the two commands if it happens again. Right now it appears to be fixed.

The only oddity is that the interface provided by my fix does NOT look quite the same as the interface for, say, the VLC file picker. It looks like it’s not using the default openSUSE theme. I have no idea why. I have to double-click to open folders in the file picker instead of single-clicking. I can live with that until the overall problem is fixed, but it’s annoying.

Quite possibly. I do a LOT of “Save Page As”, “Save Image As”, and I used the Save Page WE extension and that’s when the issue was very obvious.

Run /usr/libexec/xdg-desktop-portal --replace & and it will re-initialize the xdg-desktop-portal and you’ll get the KDE File picker again.

I’m still not sure what the proximal cause is, but this is a workaround until it’s fixed

2 Likes

I like Chrimum, but it’s starting to piss me off that something bad comes out about every three months.
I don’t use Kwallit, and I’d like to know how to get rid of it completely.

raija@localhost:~> chromium
[13742:13742:0516/221244.249603:ERROR:s/object_proxy.cc:590] Failed to call method: org.kde.KWallet.isEnabled: object_path= /modules/kwalletd6: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[13742:13742:0516/221244.249677:ERROR:ponents/os_crypt/sync/kwallet_dbus.cc:117] Error contacting kwalletd6 (isEnabled)
[13742:13742:0516/221244.250126:ERROR:s/object_proxy.cc:590] Failed to call method: org.kde.KLauncher.start_service_by_desktop_name: object_path= /KLauncher: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
[13742:13742:0516/221244.250144:ERROR:ponents/os_crypt/sync/kwallet_dbus.cc:86] Error contacting klauncher to start kwalletd6
[13742:13742:0516/221309.259412:ERROR:s/object_proxy.cc:590] Failed to call method: org.kde.KWallet.close: object_path= /modules/kwalletd6: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[13742:13742:0516/221309.259465:ERROR:ponents/os_crypt/sync/kwallet_dbus.cc:412] Error contacting kwalletd6 (close)
[13742:13742:0516/221309.461464:ERROR:tent/browser/network_service_instance_impl.cc:586] Network service crashed, restarting service.
[13742:13742:0516/221309.511519:ERROR:ponents/dbus/xdg/request.cc:169] Request ended (non-user cancelled).
[13742:13742:0516/221309.532199:ERROR:ensions/browser/service_worker/service_worker_task_queue.cc:197] DidStartWorkerFail jlgkpaicikihijadgifklkbpdajbkhjo: 3
[13742:13742:0516/221309.560216:ERROR:ensions/browser/service_worker/service_worker_task_queue.cc:197] DidStartWorkerFail oboonakemofpalcgghocfoadofidjkkk: 3
[13742:13742:0516/221309.614411:ERROR:ensions/browser/service_worker/service_worker_task_queue.cc:197] DidStartWorkerFail cfhdojbkjhnklbpkdaibdccddilifddb: 3
[13742:13768:0516/221312.619348:ERROR:gle_apis/gcm/engine/registration_request.cc:291] Registration response error message: DEPRECATED_ENDPOINT
[13742:13742:0516/221319.919240:ERROR:ome/browser/ui/webui/new_tab_page/new_tab_page_handler.cc:1353] NewTabPage loaded into a non-browser-tab context
[13742:13773:0516/221320.010520:ERROR:tent/browser/browser_main_loop.cc:278] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed
raija@localhost:~> 

I get these warnings and I still get the modified KDE file picker, not the original.

My original suggested workaround works as does setting up a new global /etc/portals.conf. However, as noted, I get some weird version of the KDE file picker which doesn’t seem to recognize the openSUSE theme or other settings like forcing me to double-click to open a folder in the picker.

(/usr/libexec/xdg-desktop-portal:10362): xdg-desktop-portal-WARNING **: 13:08:54.519: Failed to create background monitor: Failed to own background monitor D-Bus name

(/usr/libexec/xdg-desktop-portal:10362): xdg-desktop-portal-WARNING **: 13:08:54.519: No skeleton to export

(/usr/libexec/xdg-desktop-portal:10362): xdg-desktop-portal-WARNING **: 13:08:54.520: Choosing kwallet.portal for org.freedesktop.impl.portal.Secret via the deprecated UseIn key

(/usr/libexec/xdg-desktop-portal:10362): xdg-desktop-portal-WARNING **: 13:08:54.520: The preferred method to match portal implementations to desktop environments is to use the portals.conf(5) configuration file

I am using chromium --password-store=basic.

1 Like

Maybe this one:
https://bugzilla.suse.com/show_bug.cgi?id=1243207

2 Likes

Thanks!
This guide helped and Chromium works fine again.

There is a fix for this in the devel repository right now, that will make it into a Tumbleweed snapshot, just as soon as the OBS settles down.

(We’re experiencing some infrastructure issues right now), I’d suspect a few days.

4 Likes

This is probably causing my deskflow issue
https://bugzilla.opensuse.org/show_bug.cgi?id=1243304

Hey guys, the pam_kwallet update was pushed to the update-tumbleweed repo so update your system asap. It fixed my issue. Thanks to the maintainers!

1 Like

The kwallet update fixed both problems: kwallet and load/save menus :-).

Thanks!

Best,

Michael