Authentication required - Unlock Keyring [SPOILER: Vivaldi Browser!]

A perplexing development …

I’ve been running i3-wm for a couple of years now and have recently encountered a new dialog popup upon every bootup just in the last week or so:

The unlock keyring message doesn’t say which application wants access to “Default” - so how can I figure that out?

This dialog box appears after my various “windows” (per my i3 config file) are up and running each with their respective app (Konsole, nnn, Vivaldi, Thunderbird, plus another Konsole instance on a second monitor).

I’ve tried to toggle my way to a terminal to use htop so I can determine which process this dialog might be related to. But neither my keyboard nor mouse can achieve anything other than allow me to respond to the dialog seen above.

Once I provide my root password, the dialog is gone and everything else hums along just fine.

This is a new development and I can’t seem to identify its source. I guess I’d like to provide access to an authentication password somewhere that will get stored once and for all.

Haven’t found a good solution via EOS search just yet. Thoughts?

ADDED: In case this matters:

Have you recently changed your password? For automatically unlocking of the keyring the default keyring password and your user’s password should be the same.
https://wiki.archlinux.org/title/GNOME/Keyring#PAM_step
If not I would check your pam configuration maybe you accidentally over wrote one of your pam configuration files with a pacnew file. I would look somewhere in that direction.

1 Like

Thanks for the prompt reply…

  • I haven’t changed my root password since the 1980s :wink: (Perhaps it’s time)
  • My root and user passwords are the same (again, perhaps time to reconsider)
  • Not having explicitly messed with a pacnew file (other than regular yay kernel/system updates?), I’ll have to explore that further as I have no experience dealing with those files directly. Interesting thought … thanks!

I’m’ not talking about the root password but your user password, the one that you use to login to your graphical environment(i3wm).

Yes, I use the same single password for both system root and (i3) user. :man_shrugging: Providing that same password to the dialog box allows me to proceed normally from there. (And to confirm, I have not changed this password.)

Is it gnome-keyring that you are using? And what display manager are you using to start i3wm or are you just running startx from a tty from within your user profile settings?

Based on a quick process search on “keyring” (using htop) I can see that gnome-keyring-daemon is running.

According to systemctl status display-manager I can see that I’m actively running lightdm.

EDIT: Here’s an interesting entry seen from the status request above:

gkr-pam: no password is available for user was noted around the time of bootup.
That certainly seems to be relevant to my issue :thinking:

Here’s the full status info:

Jun 30 08:33:24 iMac-i3 systemd[1]: Started Light Display Manager.
Jun 30 08:33:26 iMac-i3 lightdm[673]: pam_succeed_if(lightdm-autologin:auth): requirement "user ingroup autologin" was met by user "ejm"
Jun 30 08:33:26 iMac-i3 lightdm[673]: gkr-pam: no password is available for user
Jun 30 08:33:26 iMac-i3 lightdm[673]: pam_systemd_home(lightdm-autologin:account): New sd-bus connection (system-bus-pam-systemd-home-673) opened.
Jun 30 08:33:26 iMac-i3 lightdm[673]: pam_unix(lightdm-autologin:session): session opened for user ejm(uid=1000) by ejm(uid=0)
Jun 30 08:33:26 iMac-i3 lightdm[673]: pam_systemd(lightdm-autologin:session): New sd-bus connection (system-bus-pam-systemd-673) opened.
Jun 30 08:33:26 iMac-i3 lightdm[673]: gkr-pam: couldn't unlock the login keyring.

Try resetting the keyring, what happens then?
https://wiki.archlinux.org/title/GNOME/Keyring#Resetting_the_keyring

If not I would check your pam settings for lightdm /etc/pam.d/lightdm, according to what that wiki page recommends with pam settings.

1 Like

Another update:

Well, I performed another full system update (yay) and stepped up from kernel 6.9.5-zen1-1-zen to 6.9.7-zen1-1-zen) and the request for authentication has not reared its ugly head since rebooting.

Not sure why or how, but the issue may have simply resolved itself?

EDIT @Cphusion Many thanks for your efforts … if the dialog comes back to haunt me I will certainly follow your link above to see if that addresses whatever ghost is lurking :wink:

1 Like

Great! Any other packages that were updated that stand out, any keyring or pam packages?

1 Like

Nothing out of the ordinary… believe it or not I had over a gig worth of package downloads that were involved despite simply going from 6.9.5 to 6.9.7 from a few days/weeks ago. Too many to think of tracking when I updated. :man_shrugging:

1 Like

Glad to have helped out, quite odd though you wouldn’t think that a kernel update would have an effect on something such as gnome-keyring.

That’s why I update every day so that I can decently track which packages were updated on which day, but to each their own. Either way problem is solved, but having a problem solved without knowing why only leaves you with more questions :rofl: Maybe also a reminder for everyone that has a problem to update their system before trying to debug something.

Just mark that you updated your system as a solution.

1 Like

Ha! One more tidbit … although I am NOT getting that nagging dialog box requesting password authentication anymore, I just did a systemctl status display-manager to see what I could learn…

…and I see the same gkr-pam: no password is available for user and gkr-pam: couldn't unlock the login keyring entries in the status report.

Apparently, those messages are not (directy?) related to the need to re-enter any password since I’m not being asked to do so at this point. :man_shrugging:

Confused but not perturbed.

Gee, and I thought updating weekly or so was overdoing it as OCD. I guess I need to step up to the plate. :wink:

1 Like

Maybe something to do with pam, as in the lightdm issue here?

But as they say, don’t fix what ain’t broke. :wink:

autologin could be what causing such as of the login keyring is not unlocked.

should show this:
lightdm[17527]: gkr-pam: unlocked login keyring

1 Like

Interesting… clearly I’m still not clearing this particular hurdle, since the results of the systemctl status display-manager call continue to report that gkr-pam: couldn't unlock the login keyring

But the difference since updating the kernel is that I am no longer getting that “unlock keyring authentication required” dialog box waiting for me to enter a password upon boot up. Strange.

Yet on a (very similar) EOS/i3 setup running on my laptop, I’ve just confirmed the results of the same systemctl status check show success - without any such error/warning notices. Mmmm.

Need to research this whole autologin world a bit more. Reading through etc/lightdm/lightdm.conf just now I’ve confirmed that autologin-user=ejm is there and square.

UPDATE: Okay, now I have to edit this thread to remove my own “solution” …since that same authentication dialog box has been returning … no longer immediately upon bootup since updating the kernel, but now somewhat later on after a period of using the EOS/i3 system that’s up and running. :man_shrugging:

So clearly I’ve still got the issue - likely related to the systemctl status info I’m seeing as reported above.

Alas :roll_eyes:

EDIT: So I’m now trying out the guidance provided at the link offered above by @Cphusion and will report back as to how it all works out…

YET ANOTHER UPDATE…

Well, that annoying Unlock keyring/Authentication required dialog box is popping up again in connection with bootup. But now there seems to be nothing amiss with authenticating the lightdm.service as seen in the status report below.

Cannot seem to identify which app is asking for my password [both my root and user password(s) are the same] - and entering the password satisfies the authentication request. :man_shrugging:

RESULTS OF status check on display-manager:

[ejm@iMac-i3 ~]$ systemctl status display-manager
● lightdm.service - Light Display Manager
Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled; preset: disabled)
Active: active (running) since Tue 2024-07-02 08:19:34 MDT; 50min ago
Invocation: 144cb87ca7b54d92a5d665722fb56ee5
Docs: man:lightdm(1)
Main PID: 647 (lightdm)
Tasks: 18 (limit: 19018)
Memory: 252.3M (peak: 254.2M)
CPU: 3min 4.485s
CGroup: /system.slice/lightdm.service
├─647 /usr/bin/lightdm
└─668 /usr/lib/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Jul 02 08:19:33 iMac-i3 systemd[1]: Starting Light Display Manager...
Jul 02 08:19:34 iMac-i3 systemd[1]: Started Light Display Manager.
Jul 02 08:19:35 iMac-i3 lightdm[682]: pam_succeed_if(lightdm-autologin:auth): requirement "user ingroup autologin" was met by user "ejm"
Jul 02 08:19:35 iMac-i3 lightdm[682]: pam_systemd_home(lightdm-autologin:account): New sd-bus connection (system-bus-pam-systemd-home-682) opened.
Jul 02 08:19:35 iMac-i3 lightdm[682]: pam_unix(lightdm-autologin:session): session opened for user ejm(uid=1000) by ejm(uid=0)
Jul 02 08:19:35 iMac-i3 lightdm[682]: pam_systemd(lightdm-autologin:session): New sd-bus connection (system-bus-pam-systemd-682) opened.
[ejm@iMac-i3 ~]$

One more update:

Okay, I’ve finally identified WHICH application keeps requesting the authentication/keyring unlock. Drum roll :drum:

Vivaldi.

{I stumbled upon this suspicion given that I do allow the browser to save a few innocuous logon/password combos for certain low-risk websites I’ve got bookmarked.}

And so, perusing the Vivaldi forums, I came across other users who are similarly irritated by Vivaldi’s behavior in this regard. Apparently, one can disable this, but then lose the autofill user/password feature for all websites within Vivaldi.

Although strictly speaking this isn’t necessarily a solution, at least I now know which is the offending application causing this irritating behavior.

I’ll mark this as the solution in case anyone else comes along with a similar symptom - perhaps editing the thread’s heading, too.

Thanks again to those whose assistance was offered up above. :vulcan_salute: