The bugfix that apparently caused this regression is https://bugs.kde.org/show_bug.cgi?id=508870

There's no obvious reason why this file should break kwallet-pam. Only thing I can think of is a race condition between the Secret Portal and PAM, as has been suggested in the linked forum thread. I.e. something launching the wallet via the portal before PAM has a chance to unlock it. But that doesn't sound likely to me.

At least, the password dialog appears when it should not. With this file being present, one gets the password dialog after logging in, and simply deleting it makes everything work again as before – same version of kwallet, no downgrade. No password dialog without the file.

Well, maybe kwallet-pam does work, but something queries kwallet before kwallet-pam is able to unlock kwallet, so that the password dialog pops up after logging in. Maybe kwallet-pam does unlock the wallet right after the dialog pops up, but it does pop up – and kwallet-pam's only job is to prevent this.

I would love to help debugging this, if you tell me what to do. I didn't find any logs or anything that could help tracking down what happens under the hood ...

I can reproduce this (also on Artix Linux), and a race condition seems like the cause:

Before moving the dbus service file:
$ pgrep -la ksecretd
12886 /usr/bin/ksecretd

After moving the dbus service file:
$ pgrep -la ksecretd
8441 /usr/bin/ksecretd --pam-login 13 14

With `execsnoop' I see ksecretd with --pam-login is started in both cases (as a child of `sddm-helper') but ksecretd forked from dbus-daemon races ahead of it and the one with --pam-login dies.

(In reply to CarlosE from comment #4)
> With `execsnoop' I see ksecretd with --pam-login is started in both cases
> (as a child of `sddm-helper') but ksecretd forked from dbus-daemon races
> ahead of it and the one with --pam-login dies.

Good find!
That means something is calling the org.freedesktop.portal.Secret DBus service very early during login, and then xdg-desktop-portal forwards it to org.freedesktop.impl.portal.desktop.kwallet. Can you identify who the caller is?

https://wiki.archlinux.org/title/XDG_Desktop_Portal#Configuration explains how this is configured. As a workaround, you might be able to disable the Secret portal if you don't need it with flatpak (as a more robust alternative to just deleting the DBus service activation file). Another workaround is to override just the activation file in your ~/.local/share, and point it e.g. at /usr/bin/true.

(In reply to michaelk83 from comment #5)
> (In reply to CarlosE from comment #4)
> > With `execsnoop' I see ksecretd with --pam-login is started in both cases
> > (as a child of `sddm-helper') but ksecretd forked from dbus-daemon races
> > ahead of it and the one with --pam-login dies.
> 
> Good find!
> That means something is calling the org.freedesktop.portal.Secret DBus
> service very early during login, and then xdg-desktop-portal forwards it to
> org.freedesktop.impl.portal.desktop.kwallet. Can you identify who the caller
> is?

It seems to be xdg-desktop-portal itself. dbus-daemon logs:

dbus-daemon[5289]: [session uid=1000 pid=5289 pidfd=5] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.11' (uid=1000 pid=5345 comm="/usr/bin/kcminit_startup")
[...]
dbus-daemon[5289]: [session uid=1000 pid=5289 pidfd=5] Activating service name='org.freedesktop.impl.portal.desktop.kwallet' requested by ':1.12' (uid=1000 pid=5348 comm="/usr/lib/xdg-desktop-portal")

> https://wiki.archlinux.org/title/XDG_Desktop_Portal#Configuration explains
> how this is configured.

Where, exactly? I only see instructions on how to disable the portal, not on how to log who requested it.

In the meantime, I set up an (extremely) early dbus-monitor process in my system; it seems xdg-desktop-portal calls StartServiceByName("org.freedesktop.impl.portal.PermissionStore") on its own; I don't find any processes calling for Secret-related functions.

I don't think I'm missing anything as I'm starting said dbus-monitor before the graphical session even comes up.

(In reply to CarlosE from comment #6)
> (In reply to michaelk83 from comment #5)
> > https://wiki.archlinux.org/title/XDG_Desktop_Portal#Configuration explains
> > how this is configured.
> 
> Where, exactly? I only see instructions on how to disable the portal, not on
> how to log who requested it.

By "how this is configured" I only meant how the desktop portal in general is configured. Not logging.
For logging DBus calls, you would typically use dbus-monitor, IIRC, which you're already doing.

So this looks like an internal initialization process within xdg-desktop-portal, possibly triggered by kcminit_startup. I don't think there's much we can do about that, nor about how SDDM interacts with KWallet PAM. Maybe KWallet can delay its first non-PAM start for a sec or two to give PAM a chance to unlock it first...

(In reply to michaelk83 from comment #7)
> So this looks like an internal initialization process within
> xdg-desktop-portal, possibly triggered by kcminit_startup. I don't think
> there's much we can do about that, nor about how SDDM interacts with KWallet
> PAM.

Can't kwallet-pam unlock the existing KDE wallet process? ksecretd provides a seemingly relevant org.kde.KWallet.pamOpen method.

> Maybe KWallet can delay its first non-PAM start for a sec or two to
> give PAM a chance to unlock it first...

At least on my system, the delay between spawning ksecretd instances is bigger than that (around five seconds).

(In reply to CarlosE from comment #8)
> Can't kwallet-pam unlock the existing KDE wallet process? ksecretd provides
> a seemingly relevant org.kde.KWallet.pamOpen method.

Maybe, but if ksecretd needs to unlock as soon as it's launched, then you'd still get the password prompt before kwallet-pam runs.
 
> > Maybe KWallet can delay its first non-PAM start for a sec or two to
> > give PAM a chance to unlock it first...
> 
> At least on my system, the delay between spawning ksecretd instances is
> bigger than that (around five seconds).

Yea, then that doesn't really solve it either. A 5 sec delay would definitely be noticeable to users, and could potentially cause other problems.

If we need to change how xdg-desktop-portal (or its KDE backend) or kwallet-pam are launched and initialized, that could be a rather complex fix.
For the moment, my recommended workaround is to copy the org.freedesktop.impl.portal.desktop.kwallet.service autostart file into ~/.local/share/dbus-1/services/ and set its Exec to /usr/bin/true. This is equivalent to removing the file, but won't be affected by package updates.

(In reply to michaelk83 from comment #9)
> For the moment, my recommended workaround is to copy the
> org.freedesktop.impl.portal.desktop.kwallet.service autostart file into
> ~/.local/share/dbus-1/services/ and set its Exec to /usr/bin/true. This is
> equivalent to removing the file, but won't be affected by package updates.

Or maybe /usr/bin/false is better, as that should let DBus know that something went wrong.
Either way, keep in mind that this would partially break the Secret portal (bug 508870).

So currently (without a more comprehensive fix), our choice is between a broken Secret portal or a broken kwallet-PAM.

What would be interesting what causes the early start of xdg-desktop-portal itself which is usually also dbus-activated.

I noticed the earliest calls mentioning XDG Desktop Portal were:

method call time=1758641910.820195 sender=:1.12 -> destination=org.freedesktop.portal.Desktop serial=2 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.freedesktop.portal.Screenshot"
   string "version"

Grepping for this pattern in dbus-monitors logs yielded dozens of matches. As soon as I started a new Qt application, whether CLI or GUI, a similar log line would appear. Trying to find possible culprits led me to this line in Qt's source code:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/platform/unix/qdesktopunixservices.cpp?h=6.9.2#n393

(In reply to CarlosE from comment #12)
> Trying to find possible culprits led me to this line in Qt's source code:

That seems to check whether the Desktop portal supports a particular type of screenshots. It looks like part of Qt initialization, which would explain why it runs with every Qt app, and why it runs very early in the login sequence.

This particular culprit should be fairly easy to test for, since it aborts if you have QT_NO_XDG_DESKTOP_PORTAL set to > 0. Though there still might be other things calling xdg-desktop-portal.

(In reply to michaelk83 from comment #13)
> This particular culprit should be fairly easy to test for, since it aborts
> if you have QT_NO_XDG_DESKTOP_PORTAL set to > 0. Though there still might be
> other things calling xdg-desktop-portal.

That seems to be it; adding QT_NO_XDG_DESKTOP_PORTAL=1 to /etc/environment removes the very early calls to org.freedesktop.portal.Desktop, and now ksecretd consistently has the --pam-login argument. Then the first process to call it becomes one that later requests the 'org.kde.klipper' name:

method call time=1759017937.967675 sender=:1.30 -> destination=org.freedesktop.portal.Desktop serial=402 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.portal.Settings; member=ReadAll
   array [
      string "org.kde.VirtualKeyboard"
   ]

 However, that's only two seconds after the process spawned by PAM requests the 'org.freedesktop.impl.portal.desktop.kwallet' name (though after a few tests, this seem to be enough margin for error, the original reporter might want to test if this works).

method call time=1759017935.239469 sender=:1.29 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
   string "org.freedesktop.impl.portal.desktop.kwallet"
   uint32 4

Problem is, one loses the "pick screen color" button in programs like KDEnlive/KolourPaint/etc.

So the sequence seems to be:
1. Qt initialization runs very early during login (and on each Qt app start).
2. It calls org.freedesktop.portal.Desktop to check for color picking support.
3. This triggers some internal dependencies in xdg-desktop-portal.
4. Which leads to an early call to org.freedesktop.impl.portal.desktop.kwallet (e.g. by calling org.freedesktop.portal.Secret).
5. And this launches ksecretd via the new DBus service autostart file, before kwallet-pam had a chance to unlock it.
(6. kwallet-pam still runs, but is too late, and simply aborts.)

This gives us the following workarounds, so far:
- Set QT_NO_XDG_DESKTOP_PORTAL=1 (e.g. in /etc/environment): breaks Qt color picking functions (and maybe some other things), but all the portals should still work, in principle. Or:
- Override org.freedesktop.impl.portal.desktop.kwallet.service (place a copy in your ~/.local/share/dbus-1/services/). Point its Exec at /usr/bin/false to let DBus know that something went wrong, or at /usr/bin/true to ignore it silently. This breaks KWallet auto-start when requested through the Secret portal (bug 508870). Or:
- Disable the Secret portal itself in your ~/.config, as explained in https://wiki.archlinux.org/title/XDG_Desktop_Portal#Configuration . Or:
- Leave things as is, which leaves kwallet-pam broken, but everything else works.

A proper fix may need to focus on the internal dependencies in the xdg-destktop-portal-kde implementation (steps 3-4 above). Or on the SDDM -> kwallet-pam startup sequence, but that may be more difficult, and would only fix this with SDDM.

Gemini tells me that the unwanted dependency is more likely to be in xdg-destktop-portal itself, rather than in xdg-destktop-portal-kde, mostly likely xdg-destktop-portal trying to probe all available interfaces when it's first accessed.

Having xdg-destktop-portal lazy-load the Secret portal would depend on upstream, but we came up with a few solutions that could be implemented in ksecretd. They rely on detecting and aborting the premature activation:

The 1st option is to try to detect if activation occurs during early session startup, for example by checking if org.kde.KScreen or org.kde.kded6 have launched yet (with G_DBUS_CALL_FLAGS_NO_AUTO_START or equivalent). If the session is not ready, and --pam-login is not present, abort the early activation (or at least don't show an unlock prompt).

The 2nd option is to check if kwallet-pam is configured. If it is, then specifically wait for the --pam-login argument.

A 3rd option was to differentiate generic DBus probing calls from actual method calls, and refuse to fully start on general probing. But since the DBus interface class is auto-generated, this is probably not practical.

Finally, the 4th option is to modify the DBus service activation file for org.freedesktop.impl.portal.desktop.kwallet to delegate actual activation to SystemD. Then the SystemD unit file can specify Requires=plasma-workspace.target and After=plasma-workspace.target, to block activation until the workspace is ready (by which point, kwallet-pam should have properly run).

I am on Gentoo (kwallet-6.18-0) and do not have the mentioned new file, removal of which would at least be a hack.
Is there any other fix (auto-unlock is needed for kmail and signal here for several machines)?
Downgrading is not that easy here because of several dependencies, but applying a patch would be possible.

The file in question doesn't live in kwallet, but in kwallet-pam (I have kde-plasma/kwallet-pam-6.4.5 installed on my Gentoo machine). However, I did not experience this problem on my Gentoo box yet, only on my Artix machines.

I also have kwallet-pam-6.4.5 installed, but the file in question
/usr/share/dbus-1/services/org.freedesktop.impl.portal.desktop.kwallet.service
does not exist here, so I cannot even try to fix the issue by removing it. 
Maybe because I am using openrc and not systemd?

This has nothing to do with Systemd. I'm also on OpenRC. I was wrong however – the file is in kwallet, since v6.18.0 (cf. my initial bug report). The respective commit is https://invent.kde.org/frameworks/kwallet/-/commit/ecf9e2ec7fceca538a9266f5bb9488b4dced1d09. However, Gentoo seems to package kwallet slightly different from Artix ... maybe, this is something different? As said, no problem for me on Gentoo yet. Perhaps, I simply don't run that portal stuff?

(In reply to Tobias Leupold from comment #20)
> However, Gentoo seems to package kwallet slightly different from Artix ...
We have split it up:
kde-frameworks/kwallet (src/api)
kde-frameworks/kwallet-runtime (src/runtime)
kde-frameworks/ksecretd-services (specifically to be able to ship this portal file only for systemd users)

@Tom, maybe your problem is indeed something else and fixed after syncing and updating to >=kde-plasma/kwallet-pam-6.4.5-r1.

(In reply to Andreas Sturmlechner from comment #21)
> We have split it up:
> kde-frameworks/ksecretd-services (specifically to be able to ship this
> portal file only for systemd users)

FYI, the file in question is a DBus service activation file, it has nothing to do with SystemD (both use `.service` extension, but the format and usage are unrelated).

(In reply to Tom from comment #17)
> I am on Gentoo (kwallet-6.18-0) and do not have the mentioned new file,
> removal of which would at least be a hack.
> Is there any other fix (auto-unlock is needed for kmail and signal here for
> several machines)?

Rather than removing the file, you can override it in `~/.local/`. See comment 15 for details and other options.
But since you don't have the file, you're more most likely seeing a different problem. There are many reasons why kwallet-pam can break.

(In reply to michaelk83 from comment #22)
> (In reply to Andreas Sturmlechner from comment #21)
> > We have split it up:
> > kde-frameworks/ksecretd-services (specifically to be able to ship this
> > portal file only for systemd users)
> 
> FYI, the file in question is a DBus service activation file, it has nothing
> to do with SystemD (both use `.service` extension, but the format and usage
> are unrelated).

Nevertheless, a regression surfaced with non-systemd, so that's what we did.

My problem was indeed not the one described here. I was mislead to this bug report because behaviour looked the same and appeared just after upgrading to 6.18.0
Gentoo kde-plasma/kwallet-pam-6.4.5-r1 fixes this on all of my machines. Thank you Andreas :-)
Sorry for the noise.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwallet/-/merge_requests/141

I can't comment on the linked PR due to "Your account has been blocked.", but it seems not to work on my machine. I instructed pam_kwallet to invoke a wrapper that logs ksecretd's debug output, and got this:

Jan 17 12:26:16 kf.wallet.ksecretd: ksecretd5: Checking for pam module
Jan 17 12:26:16 kf.wallet.ksecretd: ksecretd5: Got pam-login param
Jan 17 12:26:16 kf.wallet.ksecretd: ksecretd5: Waiting for hash on 14
Jan 17 12:26:16 kf.wallet.ksecretd: ksecretd5: waitingForEnvironment on: 15
Jan 17 12:26:17 kf.wallet.ksecretd: ksecretd5: client connected
Jan 17 12:26:17 kf.wallet.ksecretd: ksecretd5: client disconnected
Jan 17 12:26:17 kf.iconthemes: Icon theme "" not found.
Jan 17 12:26:17 kf.imageformats.plugins.hdr: Unknown HDR format: ""
Jan 17 12:26:17 kf.imageformats.plugins.xcf: XCF: read called on non-XCF file
Jan 17 12:26:17 kf.crash: Could not find drkonqi in search paths: QList("/usr/bin", "/usr/lib/qt6", "/usr/lib")
Jan 17 12:26:17 kf.wallet.ksecretd: D-Bus activated with PAM kwallet configured, deferring to PAM instance...
Jan 17 12:26:22 kf.wallet.ksecretd: No PAM instance detected after wait, proceeding with D-Bus activation
Jan 17 12:26:22 QThreadStorage: entry 8 destroyed before end of thread 0x55a460611320
Jan 17 12:26:22 QThreadStorage: entry 7 destroyed before end of thread 0x55a460611320
Jan 17 12:26:22 QThreadStorage: entry 1 destroyed before end of thread 0x55a460611320
Jan 17 12:26:22 QThreadStorage: entry 0 destroyed before end of thread 0x55a460611320

ksecretd from D-Bus activation still has a head start, and since both are waiting for the same amount of time, it still wins.

(In reply to CarlosE from comment #26)
> I can't comment on the linked PR due to "Your account has been blocked.",
> but it seems not to work on my machine.

I can confirm it works if the hasPamLoginArg() function is replaced by a check for `hash == nullptr` (`hash` being the variable that is initialized by the `checkPamModule` earlier in the main() function.

V4 of the MR does not work on my machine. As V1 of the MR stated[1], PAM_KWALLET5_LOGIN is also exported to the entire user session/D-Bus activation environment during login (intentionally, if my understanding of kwallet-pam's README is correct), so it's not a reliable indicator of a D-Bus launch (that is, unless the D-Bus service file is wrapped with `env -u` or some other equivalent solution).

V3 (using hash == nullptr) is the one that worked best on my machine.

If my interpretation is correct, PAM_KWALLET5_LOGIN can be expected to be present in a D-Bus activated ksecretd only if it can conflict with kwallet-pam; in that case,  `hash == nullptr && getenv("PAM_KWALLET5_LOGIN)` can be used as a trigger for the "waiting mode", with a more generous timeout since the risk of false positives is smaller.

A dead-end I investigated, for posterity: starting `/usr/bin/plasma_waitforname org.freedesktop.impl.portal.desktop.kwallet` (seems to be used for a similar purpose in Plasma, namely preventing notifications from being processed before the notification daemon is started), even if started very early in the login process, does not work.

[1] https://invent.kde.org/frameworks/kwallet/-/blob/7fc9117a9f2bf28d92e7d0b3a390841255209919/src/runtime/ksecretd/main.cpp#L232

(In reply to CarlosE from comment #28)
> V4 of the MR does not work on my machine. As V1 of the MR stated[1],
> PAM_KWALLET5_LOGIN is also exported to the entire user session/D-Bus
> activation environment

AFAICT, it's set directly by PAM:
https://invent.kde.org/plasma/kwallet-pam/-/blob/master/pam_kwallet.c#L486
https://invent.kde.org/plasma/kwallet-pam/-/blob/master/pam_kwallet.c#L117
So _should_ only apply to the PAM process. You may need to investigate why it's failing on your system.

Also try contacting sysadmin@kde.org regarding your MR login issue.

Git commit 211ac63a8c0dc6f90989dfb665d894a2a9d46eb9 by Marco Martin, on behalf of Bosco Robinson.
Committed on 03/02/2026 at 09:37.
Pushed by mart into branch 'master'.

Fix D-Bus activation race with PAM-launched ksecretd

When xdg-desktop-portal probes for the Secret Service during login,
it triggers D-Bus activation of ksecretd before kwallet-pam has
finished launching it with the password hash. The premature instance
grabs the bus name, blocking the PAM instance from auto-unlocking
the wallet.

Use KDBusService::Replace when launched by PAM (hash != nullptr) so
the PAM instance takes over the bus name from any premature D-Bus
activation. Non-PAM instances use plain Unique as before.

M  +6    -1    src/runtime/ksecretd/main.cpp

https://invent.kde.org/frameworks/kwallet/-/commit/211ac63a8c0dc6f90989dfb665d894a2a9d46eb9