Confirmed. Since the move to ksecretd, kwalletd crashes early during the login, and that causes a delay of ~10-15 seconds to the login until the wallet window is displayed. Once the wallet is unlocked, the rest of the session starts.

(In reply to Luca Beltrame from comment #1)
> Confirmed. Since the move to ksecretd, kwalletd crashes early during the
> login, and that causes a delay of ~10-15 seconds to the login until the
> wallet window is displayed. Once the wallet is unlocked, the rest of the
> session starts.

While Qt complains about being unable to load a platform plugin, I wonder if it's a red herring (happens on both X11 and Wayland sessions).

I built kwallet-pam with -DKWALLETD_BIN_PATH=/usr/bin/ksecretd and it seems to work fine.

The reason (thanks to Fabian Vogt for noticing) is that the `kwalletd6` command (the thin wrapper around ksecretd) dropped the --pam-login option, so it will no longer work as expected.

Might https://invent.kde.org/frameworks/kwallet/-/commit/d79ef6bfbc59aa82a7e22df883b70abc25b569a1 fix it?

*** Bug 504248 has been marked as a duplicate of this bug. ***

*** Bug 504082 has been marked as a duplicate of this bug. ***

*** Bug 504082 has been marked as a duplicate of this bug. ***

*** Bug 504254 has been marked as a duplicate of this bug. ***

are those problems happening from distribution packages or self built?

if kwalletd is rebuilt before kwallet-pam then kwallet-pam should take the correct variable and start ksecretd instead of kwallet.

an alternative is to rebuild kwallet-pam with the -DKWALLETD_BIN_PATH=/usr/bin/ksecretd 

it is a bit more concerning if in some distributions this still happens out of the box as would imply something wrong in the build process

It's happening with distribution packages. I did a fresh openSUSE tumbleweed install with snapshot 20250514.

(In reply to Mariusz from comment #11)
> It's happening with distribution packages. I did a fresh openSUSE tumbleweed
> install with snapshot 20250514.

Is there a bug report for openSUSE?
https://invent.kde.org/frameworks/kwallet/-/commit/d79ef6bfbc59aa82a7e22df883b70abc25b569a1 is 3 weeks old, and should have fixed the issue, I think (based on comment 3 and BUG 504082 comment 4).

Ack.

This whole situation could definitely have been done better and there are maybe broken setups still but from a Plasma POV I think we can consider this resolved. The next plasma's will have the right defaults so there's nothing else we can do upstream.

Marco, did you email the distro packagers about the situation?

Just for my understanding, from what exact version should this issue be resolved?

Because the remote desktop app Remmina on Arch has kept asking me for password on every login since a week or so.
And I just updated again, and the issue is currently still there. Maybe I just have to wait a bit longer I guess.

See my reply here: https://bugs.kde.org/show_bug.cgi?id=504014#c38
I have been directed to this issue from there.

solved with openSUSE Tumbleweed.

Operating System: openSUSE Tumbleweed 20250515
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-1-default (64-bit)
Graphics Platform: Wayland

pam-kwallet6 6.3.5-2.1
pam-kwallet6-common 6.3.5-2.1

(In reply to Philippe ROUBACH from comment #15)
> solved with openSUSE Tumbleweed.
> pam-kwallet6 6.3.5-2.1
> pam-kwallet6-common 6.3.5-2.1

ok, good to hear this,

I think this means is definitely solved.

I think opensuse had in kwallet did an explicit -DKWALLETD_BIN_PATH so if now has been updated, it means this bug was that known issue

I have a feeling between updates either the .kwl file got corrupted or something changed that doesn't allow a passwordless wallet (as I have, what I store in kwallet is not that sensitive). 

I still can't open wallet.

(In reply to dezzadk from comment #17)
> I have a feeling between updates either the .kwl file got corrupted or
> something changed that doesn't allow a passwordless wallet (as I have, what
> I store in kwallet is not that sensitive). 
> 
> I still can't open wallet.

Please check your deny list in the wallet settings. See bug 504193 comment 12.

In my case after applying the patch on Tumbleweed I've noticed after updating that kWalletManager still shows the wallet as closed upon launch until it's explicitly opened, even though the opening doesn't require a password anymore and it seems apps can still access the secrets...

(In reply to michaelk83 from comment #18)
> (In reply to dezzadk from comment #17)
> > I have a feeling between updates either the .kwl file got corrupted or
> > something changed that doesn't allow a passwordless wallet (as I have, what
> > I store in kwallet is not that sensitive). 
> > 
> > I still can't open wallet.
> 
> Please check your deny list in the wallet settings. See bug 504193 comment
> 12.

That was it, thank you very much for the response. I restarted plasma desktop first- saw the same symptoms, but then I launched KDE Wallet from System Settings and got the prompt to Allow KDE and once I did the wallet finally opened I had `qdbus6 org.kde.kwalletd6 /modules/kwalletd6 open kdewallet 0 'foo'` running in a terminal meanwhile which finished executing right after.

(In reply to Marco Martin from comment #16)
> (In reply to Philippe ROUBACH from comment #15)
> > solved with openSUSE Tumbleweed.
> > pam-kwallet6 6.3.5-2.1
> > pam-kwallet6-common 6.3.5-2.1
> 
> ok, good to hear this,
> 
> I think this means is definitely solved.
> 
> I think opensuse had in kwallet did an explicit -DKWALLETD_BIN_PATH so if
> now has been updated, it means this bug was that known issue

You right, KWALLET_BIN_PATH was pointing to kwalletd6. It has been updated to ksecretd and it's now working again.

Ok, because my problems with Remmina are still there (Arch Linux), I investigated some things myself now, with the help of HTOP to check what processes with names "kwallet|ksecret" are launched when I start Remmina versus which ones are launched by other applications like Chromium.
Turns out that Remmina still uses kwalletd5. I don't have the knowledge how things are exactly wired, but this seems like an older version and it looks a lot like a compatibility problem has been introduced.
Until very recently it all worked without issues for me. With the very recent updates the password prompt issue started.
When I downgrade to kwallet 6.13.0-1 and kwallet-pam 6.3.5-1, my problem stops.
This is without upgrading or downgrading kwallet5, which sits at version 5.116.0-1. It's still a dependency of multiple other packages.
I have to mention that Remmina does not show up in the list of connected applications in the Kwallet Manager anyway, while Chromium does, but I am not sure if that matters.

(In reply to Eduard from comment #22)
> Ok, because my problems with Remmina are still there (Arch Linux), I
> investigated some things myself ...
> Turns out that Remmina still uses kwalletd5. ...
> When I downgrade to kwallet 6.13.0-1 and kwallet-pam 6.3.5-1, my problem
> stops.
> This is without upgrading or downgrading kwallet5, which sits at version
> 5.116.0-1. It's still a dependency of multiple other packages.

kwallet 6 provides both a kwalletd5 and kwalletd6 API endpoints from the same binary. But I don't know how that works if you also have a kwallet5 package installed side-by-side. If you actually have a kwalletd5 *binary* running, that's probably from that other package.

AFAIK, kwallet-pam can only auto-unlock one or the other, not both. If Arch applied the latest patches, then the latest kwallet-pam should be unlocking the new kwallet.

> I have to mention that Remmina does not show up in the list of connected
> applications in the Kwallet Manager anyway, while Chromium does

By "connected applications", do you mean the stored passwords list, or the Allow/Deny lists? If Remmina doesn't show up in the stored passwords, then that would explain why it's asking you for a password: even if the wallet is unlocked, it can't find its password there.
Do also check your deny list just in case.

Could it be that you have two different wallets, and Remmina's password is in the other one? When you downgrade to 6.13, do you see it in the passwords list in KWalletManager?

> kwallet 6 provides both a kwalletd5 and kwalletd6 API endpoints from the
> same binary. But I don't know how that works if you also have a kwallet5
> package installed side-by-side. If you actually have a kwalletd5 *binary*
> running, that's probably from that other package.
Yes kwalletd5 is installed by package kwallet5. I can confirm that.
I didn't install it manually, it's a required dependency by two other packages called kio5 and qtkeychain-qt6. This is how Arch Linux has configured things (I have the good habit to remove any package installed as dependency which is not longer needed, to keep my system as clean as posible).

> AFAIK, kwallet-pam can only auto-unlock one or the other, not both. If Arch
> applied the latest patches, then the latest kwallet-pam should be unlocking
> the new kwallet.
With Chromium it does so, although the kwalletmanager seems to have a refresh issue in which it doesn't immediately show things.

> > I have to mention that Remmina does not show up in the list of connected
> > applications in the Kwallet Manager anyway, while Chromium does
>
> By "connected applications", do you mean the stored passwords list, or the
> Allow/Deny lists? If Remmina doesn't show up in the stored passwords, then
> that would explain why it's asking you for a password: even if the wallet is
> unlocked, it can't find its password there.
> Do also check your deny list just in case.
Ok, I now decided to launch things with LANG=C set (my system is configured Dutch), so that I can read correct English descriptions...
In the KWallet Manager (the binary is still called 'kwalletmanager5' apparently), it's the tab called "Applications" what I was talking about, not "Contents" (where all the passwords are).
And then it's the upper part "These applications are currently connected to this wallet".
Only kwalletmanager and Chromium show up there, Remmina never does (also not after downgrading to the older kwallet version where the password prompt issue doesn't happen), which surprised me.
Below that in the same tab is "These applications are authorized to access the wallet". That must be the allow/deny list. It's empty. When I check "Access Control" in KDE Wallet section in the systemsettings, which seems a redundant overview, that's empty as well (there are no buttons to add anything either, I don't even know how I would do that).

> Could it be that you have two different wallets, and Remmina's password is
> in the other one? When you downgrade to 6.13, do you see it in the passwords
> list in KWalletManager?
All passwords are in the same wallet, Remmina has it's own folder in there, even with it's own icon. When I manually change some password, these changes also reflect into the application, so there isn't anything else.

(In reply to Eduard from comment #24)
> Yes kwalletd5 is installed by package kwallet5.
> it's a required dependency (of) kio5 and qtkeychain-qt6.

Checking the package dependencies, qtkeychain-qt6 only depends on the new kwallet package, and even that is optional.
It does require org.freedesktop.secrets, but that can be provided by the new kwallet.
kio5 does require kwallet5, but are you sure you still need kio5 itself? There's kio 6 already, which you very likely have installed.
https://archlinux.org/packages/extra/x86_64/qtkeychain-qt6/
https://archlinux.org/packages/extra/x86_64/kio5/
https://archlinux.org/packages/extra/x86_64/kio/

You can try to dry-run remove kwallet5, after making sure you have kio 6 installed, to see if it would remove anything it shouldn't.
If kwallet5 can be removed safely, then that might remove some mutual interference. The new kwallet will provide the kwalletd5 interface.

> I now decided to launch things with LANG=C set,
> so that I can read correct English descriptions...

As long as Remmina is in the passwords list (as you say it is), and not in the deny list (which you say is empty), that should be good enough. You can leave the rest as it was.

If you say the wallet is being unlocked, and the password is there, then there must be some other reason that Remmina can't find it. Maybe removing the extra kwallet5 will fix that. You can also try to configure Remmina to use the Secret Service API, which the new wallet supports. Maybe it'll find its password that way.

(In reply to michaelk83 from comment #25)

Both kio (6.14.0-1) and kio5 (kio5 5.116.0-2) are on my system.
If I don't want kio5, I seem to no longer be able to have any application groups installed like I do now.

First when I do indeed some dry runs, it quickly becomes clear that it's quite complicated:

$ LANG=C pacman -Rsp kio5
error: failed to prepare transaction (could not satisfy dependencies)
:: removing kio5 breaks dependency 'kio5' required by cervisia
:: removing kio5 breaks dependency 'kio5' required by kalzium
:: removing kio5 breaks dependency 'kio5' required by kamoso
:: removing kio5 breaks dependency 'kio5' required by kdeclarative5
:: removing kio5 breaks dependency 'kio5' required by knewstuff5
:: removing kio5 breaks dependency 'kio5' required by kparts5
:: removing kio5 breaks dependency 'kio5' required by purpose5
:: removing kio5 breaks dependency 'kio5' required by step
:: removing kio5 breaks dependency 'kio5' required by umbrello
$ LANG=C pacman -Rsp umbrello
error: failed to prepare transaction (could not satisfy dependencies)
:: removing umbrello breaks dependency 'umbrello' required by kde-sdk-meta
$ LANG=C pacman -Rsp cervisia
error: failed to prepare transaction (could not satisfy dependencies)
:: removing cervisia breaks dependency 'cervisia' required by kde-sdk-meta
$ LANG=C pacman -Rsp kde-sdk-meta
error: failed to prepare transaction (could not satisfy dependencies)
:: removing kde-sdk-meta breaks dependency 'kde-sdk-meta' required by kde-applications-meta

Then, if I remove 'kde-applications-meta' and mark it's dependencies as explicit, I still will have to remove a lot it's subgroups.
The packages required by kio5 are part of kde-applications, kde-education, kde-sdk-meta and more.

When simply I manually rename the binary /usr/bin/kwalletd5 to something else (like just adding an underscore to it), that also doesn't work, Remmina no longer prompts for login, but it also shows empty passwords for my configurations, so it no longer accesses kwallet. Renaming it back and restarting Remmina makes Remmina work again, but prompt for password input again too.

When I check the Remmina code on gitlab (https://gitlab.com/Remmina/Remmina), I also see no references to kwallet 6, it's all kwalletd5.


What I find really interesting though, when I launch the KWallet Manager and manually click to open the wallet first, before starting Remmina, it seems the login prompt doesn't appear at all and Remmina just works, it also does not want to launch kwalletd5.
Shouldn't it do that automatically on startup after login? I'm getting even more confused.

(In reply to Eduard from comment #26)
> When I check the Remmina code on gitlab (https://gitlab.com/Remmina/Remmina),
> I also see no references to kwallet 6, it's all kwalletd5.

I only see two references to org.kde.kwalletd5, which is the API endpoint, not the binary. This endpoint is also provided by the new kwallet.
Basically, Remmina makes calls to the API, and that probably launches the wallet via DBus activation (if it's not already running). If it ends up launching the old binary, likely your DBus activation file for org.kde.kwalletd5 is pointing at the old binary. You can override that by creating a ~/.local/share/dbus-1/services/org.kde.kwalletd5.service file with the following content:

> [D-BUS Service]
> Name=org.kde.kwalletd5
> Exec=/usr/bin/kwalletd6

> What I find really interesting though, when I launch the KWallet Manager and
> manually click to open the wallet first, before starting Remmina, it seems
> the login prompt doesn't appear at all and Remmina just works, it also does
> not want to launch kwalletd5.
> Shouldn't it do that automatically on startup after login? I'm getting even
> more confused.

Yes, that's what the patch in this issue is supposed to fix. I don't know if Arch already applied it though.

(In reply to michaelk83 from comment #27)
> I only see two references to org.kde.kwalletd5, which is the API endpoint,
> not the binary. This endpoint is also provided by the new kwallet.
> Basically, Remmina makes calls to the API, and that probably launches the
> wallet via DBus activation (if it's not already running). If it ends up
> launching the old binary, likely your DBus activation file for
> org.kde.kwalletd5 is pointing at the old binary. You can override that by
> creating a ~/.local/share/dbus-1/services/org.kde.kwalletd5.service file
> with the following content:
> 
> > [D-BUS Service]
> > Name=org.kde.kwalletd5
> > Exec=/usr/bin/kwalletd6
Thanks! Amazing. That fixes it. Yes there's a `org.kde.kwalletd5.service` and a `org.kde.kwalletd6.service` in `/usr/share/dbus-1/services/`, and the first one still has `Exec=/usr/bin/kwalletd5` configured.
Putting it in ~/.local/share/dbus-1/services/ and adjusting it does indeed fix it.
Remmina does not ask for a password anymore after login into the KDE desktop and I see kwalletd6 running and no longer kwalletd5.
The KWalllet Manager also shows an open wallet.
I'm learning new things here, really useful. Just lacked exact knowledge about how things where wired, but it's not difficult to understand.

> Yes, that's what the patch in this issue is supposed to fix. I don't know if
> Arch already applied it though.
I see. So that Remmina would not even have to do it. Probably Arch hasn't applied it yet then.

And it's also up to them to eventually fix the path in `org.kde.kwalletd5.service`, but I guess they are probably not going to change that as long as they have the kwallet5 package still in the repos (since that's still the package which owns that file, putting another version in the version 6 kwallet package would create a conflict I guess).

(In reply to Eduard from comment #28)
> Probably Arch hasn't applied it yet then.

Probably. It should be out with the next version.

> putting another version in the version 6 kwallet package would create a conflict I guess).

There is indeed a conflict here. The file with the old path is from your kwallet5 package. The kwallet 6 package has it set correctly:
https://invent.kde.org/frameworks/kwallet/-/blob/v6.14.0/src/runtime/kwalletd/org.kde.kwalletd5.service.in?ref_type=tags

Normally, you shouldn't have both of those packages installed side-by-side. But in your case, removing kwallet5 breaks others things, as you saw.

Shipping /usr/bin/kwalletd5 would be a packaging bug. kwallet5 should only ship the library component, not the daemon.

https://gitlab.archlinux.org/archlinux/packaging/packages/kwallet5/-/commit/17b919b0a298fef2b35b734b66f8e9afd2ee6e47 seems to fix this

(In reply to Nicolas Fella from comment #30)
> Shipping /usr/bin/kwalletd5 would be a packaging bug. kwallet5 should only
> ship the library component, not the daemon.
> 
> https://gitlab.archlinux.org/archlinux/packaging/packages/kwallet5/-/commit/
> 17b919b0a298fef2b35b734b66f8e9afd2ee6e47 seems to fix this

I don't know the packaging details. Maybe it's from some related package, or left over from an earlier version. If I look at the package file lists, kwallet5 5.116.0-2 indeed doesn't include `/usr/bin/kwalletd5`.
I also don't see the `org.kde.kwalletd5.service` DBus activation file in neither kwallet5 5.116.0-2 nor kwallet 6.14.1-1, but the latter does ship both `org.kde.kwalletd6.service` and `usr/bin/kwalletd6`.

Point is, he has a bunch of KF5 leftovers in parallel to KF6. And while that may still be supported by updating legacy packages to remove such conflicting files, it's not ideal. Some package managers may not properly clean up such removed files.

Ideally, his remaining KF5 apps should be migrating to KF6, so that he can remove those remnants without breaking things. But these are discussions for another place.

Ok, it looks like someone has done a bit of homework. :)

That patch on the Arch GitLab for 5.116.0-2 is from 14 hours ago now.

My situation, before updating, still being on 5.116.0-1:
$ pacman -Ql kwallet5 | grep '/usr/bin/\|/usr/share/dbus-1/services/'
kwallet5 /usr/bin/
kwallet5 /usr/bin/kwalletd5
kwallet5 /usr/share/dbus-1/services/
kwallet5 /usr/share/dbus-1/services/org.kde.kwalletd5.service

So both relevant files where really part of the package.

After I updating to 5.116.0-2, running the same comment again:
$ pacman -Ql kwallet5 | grep '/usr/bin/\|/usr/share/dbus-1/services/'
(no results)

I still need the extra file in ~/.local/share/dbus-1/services/org.kde.kwalletd5.service for Remmina, but that's fine for now.
I think they'll probably solve that in a while as well.