You are not logged in.
Recently, Google-Chrome lost (almost?) all stored browser-cookies + autofill-credentials. In addition, "Remote Desktop Viewer" application lost a saved password to a machine I connect to frequently. When trying to (again) save passwd, I get an error popup telling me "Error saving the credentials on the keyring. The name is not activatable" (consequently, the password is not actually stored; this happens persistently). As for google-chrome, I can tell it to store new passwords (again), but it will - with some few exceptions - silently discard any passwords / entered values. I think those issues are likely related, esp. considering those issues started to occur at about the same time.
I am not aware of any change I did (except running package-updates (pacman -Syu) + occasionally rebooting); it has been working flawlessly for the past couple of years (so I never actually had a closer look e.g. towards keyring).
I did some google-searching + looked at some logs I am aware of (e.g. dmesg), but could not spot anything suspicious. I run Cinnamon as DE.
Any hints about how I might further debug this issue are greatly appreciated.
Last edited by dr1fter (2024-11-16 15:56:45)
Offline
update: turns out the issue (for google-chrome) could be fixed by unlinking the following files:
"$HOME/.config/google-chrome/Default/Login Data"
"$HOME/.config/google-chrome/Default/Login Data For Account"
Offline
\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Do you by unlinking actually mean https://man.archlinux.org/man/core/core … nlink.1.en or were those symlinks?
Did you cross disks in that case (ie. the target was maybe read-only or stale)?
Offline
@seth: well, only one out of two of the described issues was resolved (-> google-chrome's autofill works again, whereas "Remote Desktop Viewer" still will fail to successfully). will still mark the thread as solved (the google-chrome issue bugged me a lot more :-))
yes, I meant the linked `unlink` command - the mentioned files were regular files (no symlinks). after removal + restart of google-chrome, both files were re-initialised (and in my case, also populated), resulting in my stored passwords/values being available again in google-chrome.
Last edited by dr1fter (2024-11-16 15:58:08)
Offline
Ah, sorry.
No shopping list, please
In addition, "Remote Desktop Viewer" application lost a saved password to a machine I connect to frequently.
Have you been using/are you using some wallet (kwallet, gnome-keyring etc et pp)?
Offline
@seth: sry about mixing those topics (although I thought they were related)
as to you question: I am not aware of using a wallet/keyring (and did not find anthing using `pacman -Q | grep key`)
Offline
What's you desktop environment and what exactly is the "Remote Desktop Viewer", https://wiki.archlinux.org/title/List_o … op_clients ?
Though chromium (and probably chrome) can force an approach and probably only support kwallet and GKR.
Offline
I use `vinagre` as remote-desktop-viewer; my Desktop-Environment is `cinnamon`
Last edited by dr1fter (2024-11-20 09:37:50)
Offline
Sure you don't have GKR?
pacman -Qs keyring
ps aux | grep keyring
https://archlinux.org/packages/extra/x86_64/vinagre/ depend on https://archlinux.org/packages/core/x86_64/libsecret/ which (optionally) depends on
org.freedesktop.secrets (gnome-keyring, keepassxc, kwallet5, kwallet) (optional) - secret storage backend
and I assume you're gonna require one of those (in doubt the ass keeper) to store the password.
Offline
pacman -Qs keyring
local/archlinux-keyring 20241015-1
Arch Linux PGP keyring
$ ps aux | grep keyring
dr1fter 674735 0.0 0.0 6752 4024 pts/2 S+ 17:40 0:00 grep keyring
It makes sense to me that I am required to have a keyring/secrets-store to keep passwords. I just wonder how this might have worked before, and then stopped working (without any related changes I am aware of / did)
Offline
libsecret seems to have a file backend, but that also seems to require you to decrypt it on every access (and issue the password for that) but "The name is not activatable" sounds a lot like it's set on using some keyring/wallet.
But https://archlinux.org/packages/core/x86_64/libsecret/ also hasn't been updates since february.
You could strace vinagre and see what files it tries to acces (and fails)
Offline
okay, will give `strace` a shot (I suppose that's a nice task for a rainy day :-))
Offline