"No such secret collection at path '/'"

Help
1 
Dec 15 17:48:09 computerName systemd[1991877]: Started app-org.chromium.Chromium-2034988.scope.
Dec 15 17:48:14 computerName kwalletd6[2028041]: "No such secret collection at path: /"
Dec 15 17:48:14 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1409286148 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed
Dec 15 17:48:16 computerName systemd[1991877]: app-org.chromium.Chromium-2034988.scope: Consumed 1.194s CPU time, 38.1M memory peak.

In the past, I would normally start chrome with –password-store=gnome-libsecret (which “gnome-libsecret” seems hidden from any documentation).

That would work out fine, and I’d click on 2 “allow” notifications at the start (yes, I know I can set it to allow always).

Now, I thought I’d let it determine the password-store itself, expecting it to default to kwallet, which I see referenced in the strace: sendmsg(71, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\0\0\0\0\3\0\0\0k\0\0\0\2\1s\0\17\0\0\0org.kde.KWallet<…>

I’ve also got keepassxc, so I set kwalletrc:

[KSecretD]
Enabled=false

Now when I run chrome without password-store set, I get the password prompt, and the 1st allow prompt, but where there should be a 2nd, I instead get a prompt to create a new kp database.

After I close chrome since I consider that a failure, about a minute or few, new prompts come up like for asking my gpg pw.

Log:

Dec 15 17:48:20 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1426063361 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed
Dec 15 17:48:27 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1442840579 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed
Dec 15 17:49:01 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1459617794 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed
Dec 15 17:49:09 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1593835525 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed
Dec 15 17:49:13 computerName kwalletd6[2028041]: Migrating "kdewallet"
Dec 15 17:49:15 computerName gpg-agent[2015758]: failed to unprotect the secret key: Operation cancelled
Dec 15 17:49:15 computerName gpg-agent[2015758]: failed to read the secret key
Dec 15 17:49:15 computerName gpg-agent[2015758]: command 'PKDECRYPT' failed: Operation cancelled <Pinentry>
Dec 15 17:49:15 computerName kwalletd6[2028041]: QObject::killTimer(): Error: timer id 1644167172 is not valid for object 0x7ffefe329300 (KWalletD, ), timer has not been killed

I’ve no clue why it’s wanting to migrate (I did see migration referenced in the rc).

Even Default Wallet= shows my keepass db, but not any other list options (no *.kwl files either).

Enabling KSecretD via Wallet Configuration still caused keepass to be called via secret service.

Closing out keepass, and “New Wallet” prompts for a name, but does nothing:

Dec 15 18:02:32 computerName kwalletd6[2035988]: "The name is not activatable"
Dec 15 18:02:32 computerName kwalletd6[2035988]: "Could not connect to Secret Service"

I’ll add that $ kwallet-query -l ~/.local/share/kwalletd/kdewallet.kwl results in Wallet /home/userName/.local/share/kwalletd/kdewallet.kwl not found, yet an ls shows it’s there.

2

Since I can’t edit my post again, I’ll also add here that it seems the query was just looking for a “name” and not a file, however the file is not listed as an option.

EDIT0: Well that got a little scary. When I went to re-open keepass, it prompted for my GPG pw and I escaped out of those prompts and keepass never opened. After trying it a 2nd time, it opened, with no GPG prompts.

3

I see that when I close keepass, stop the dbus-:1.2-org.kde.kwalletd6@ service, open kwallet manager, that service is started back up, as well as dbus-:1.2-org.kde.secretservicecompat@ service, and the *.kwl file is found.

Now that I got the kwl file back, I can no longer go back to the keepass secrets, even with apiEnabled=false.

With the qdbus-viewer, I see:

org.freedesktop.secrets (keepass)

org.kde.ksecretd (ksecretd)

org.kde.secretservicecompat (ksecret)

When I $ systemctl --user stop dbus-:1.2-org.freedesktop.impl.portal.desktop.kwallet@<#>.service, those bottom 2 entries disappear.

But when I start the KDE Wallet configuration, they come right back.

I can stop and mask the service so those entries don’t occur, but there still is no keepass secret service overtake.

The Secret Service interface lets applications store passwords and other confidential data. Disable this to allow third-party wallet services such as KeePassXC or GNOME Keyring to manage it instead.

It’s disabled and keepass isn’t “manag[ing]” it even though it’s dbus entry is still there.

It’s like I need to still force the use of password-store for gnome-libsecret while I was expecting kwallet to just pass the call to org.freedesktop.secrets.

Is my thinking wrong? How did I have it partially working before I messed with things?

4

It seems that I also needed (in kwalletrc):

[KSecretD]
Enabled=false

A setting that does not exist in KDE Wallet Configuration.

After setting that and stopping the 2 kwallet/secret dbus services, when I opened Configuration, it now shows my keepass as Default Wallet.

So, I’m open to being corrected, but I’m thinking Use KWallet for the Secret Service interface option should be setting both KSecretD and org.freedesktop.secrets settings. in kwalletrc.

EDIT0: Mind you, this does NOT correct the fact that chromium’s unused password-store (defaulting to kwallet) still results in the request for a new keepass database being created.

5

Well this is odd… I went ahead and wiped out that .config/chromium to start fresh (it was new anyway), and without using the password-store parameter, keepass is called only once, and no call to create a new database.

No clue what that would’ve been caused by.

6

Okay, I cannot even begin to say just how bad kwallet is (I had just made another post for another issue with it)…

I’m now finding this OP issue in the title has no relation to the browser in any way,

I’ve got KWalletManager open, and normally the database filename is displayed, and when I open the wallet, the title set in the database is then displayed.

When I close the wallet, the filename should be named, but it’s behaving as if the wallet isn’t even closed (even if I choose Close All Wallets), even though it says The wallet is currently closed.

So when I try to open the (supposedly closed) wallet in that manager, it gives me that very same “create database” window for keepass. HOW!? WHY!?

And in the log is that very same message in the title.

I’m hoping I can just disable kwallet and use keepass for everything.

I only have kwallet because it’s a dependency, so I don’t know what may end up breaking once I disable it.

7

While I can disable kwalletd with Enable the KDE wallet subsystem (Enabled=false), running chrome without password-store still attempts to start up the kwallet dbus: Started dbus-:1.2-org.kde.kwalletd6@<#>.service, which expectedly fails with status=255/EXCEPTION.

So it looks like I still have to force the use of keepass with password-store.

It’s a shame the browser doesn’t try any other store options (gnome/basic) if the first detected fails.

I’m noticing mention of /usr/lib/xdg-desktop-portal in the log about the expected kwallet failure, so maybe I can set a variable to ignore kwallet altogether.

And to go on how bad it is, I didn’t even mention when I was stopping the kwallet related dbus services, one of the times, it killed my entire user session. Dead. Don’t save anything. Don’t pass Go. Straight to SDDM.

No wait, it didn’t go to SDDM, I had to switch tty and kill that session that was only a black screen with a cursor position at the top-left. THEN it got me to SDDM.

EDIT0: I think I may have something: /usr/share/xdg-desktop-portal/kde-portals.conf mentions org.freedesktop.impl.portal.Secret=kwallet.

Time to make my own.

8

Going by D-Bus - ArchWiki , I had attempted to override ~/.local/share/dbus-1/services/org.freedesktop.impl.portal.desktop.kwallet.service, pointing the Exec to keepassxc, but that didn’t work.

Same with org.kde.kwalletd6.service, and both still showed the dbus-:1.2-org.kde.kwalletd6@<#>.serviceloading up kwallet instead of keepassxc. And each browser run resulted in 2 attempts for keepassxc creating a new database.

That made me question the XDG_DATA_HOME env var, because I’m not seeing that nor XDG_DATA_DIRS being set in Arch.

That makes me question <standard_session_servicedirs/> (dbus-daemon.1), as I can’t tell if where XDG_DATA_HOME defaults to ~/.local/share means it defaults to that path if the var isn’t specifically set?

9

I had updated my system and backed-up my user profile, created a fresh replacement, moved my XDG paths over, disabled kwallet’s SSI checkbox (apiEnabled=false), and manually disabled [KSecretD], and the create database is still an issue.

There was also some things I had been doing and I saw the log truly flood with some kwallet manager service dying/restarting. There was over 1000 incremented @ instances of the service before I finally stopped it.

Another interesting finding when I go to the SSI settings of keepass, is that I see 2 instances of kwalletd are currently connected via dbus.

Maybe not so “interesting” if kwalletd is expected to connect to it, instead of using ksecret.

But 2 dbus connections, even though no app is making any request to it (that I know of)?