Hallo,
seit einem der letzten Updates bekomme ich nach dem Hochfahren und Einloggen des Rechners immer die Meldung "The login keyring did not get unlocked when you logged into your computer" und ich muss mein login Passwort nochmal eingeben. Vorher war das Entsperren automatisch beim Anmelden erfolgt. Kann man das irgendwo einstellen?
Verstehe ich jetzt nicht richtig. Hast du einen Passwort-Manager?
Wird das Netzwerk/Wi-Fi nicht entsperrt, oder was wird nicht entsperrt?
Ich habe keine Ahnung, was es mit diesem login keyring auf sich hat. Es hat weder etwas mit dem Netzwerk noch mit einem Passwortmanager zu tun. Die Meldung erscheint nachdem ich mich eingeloggt habe und ich muss mein login Passwort nochmal eingeben, ansonsten kann ich nicht weiterarbeiten. Das Problem habe ich übrigens sowohl auf dem Desktop Rechner als auch auf dem Laptop seit einem der letzten Upgrades.
Anscheinend wurde vorher dieser keyring automatisch beim Anmelden entsperrt, was jetzt wohl nicht mehr so ist.
I had similar problem this morning but only one app affected Tuta mail. Looking at Kwallet setting "use secret service" had been selected ( previously off) which looks like it disables access to passwords from KeePassXC, I unselected secret service and it seems to be working OK again
Quote from: harley-peter on 2026/08/28, 09:10:24Ich habe keine Ahnung, was es mit diesem login keyring auf sich hat. Es hat weder etwas mit dem Netzwerk noch mit einem Passwortmanager zu tun. Die Meldung erscheint nachdem ich mich eingeloggt habe und ich muss mein login Passwort nochmal eingeben, ansonsten kann ich nicht weiterarbeiten. Das Problem habe ich übrigens sowohl auf dem Desktop Rechner als auch auf dem Laptop seit einem der letzten Upgrades.
Anscheinend wurde vorher dieser keyring automatisch beim Anmelden entsperrt, was jetzt wohl nicht mehr so ist.
This may be related to the issue you had with the gnome packages. Did you remove gnome-keyring? It was likely the password manager in use for Xfce. Kde users have something else. If you did remove it just reinstall it. It doesn't have a bunch of gnome depends.
I had a similar behavior when starting Nextcloud:
"Authenticaton required
The login keyring did not get unlocked whe you logged into your computer"
Then I entered my normal user password and it worked again.
The message is most likely triggered by the gnome password manager and
indicates an inconsistency between login and wallet passwords (handed down
to the respective applications by the pam service during login). The KDE
environment does not require a gnome password manager, but some
applications do and pull it in via their dependencies. The gnome password
manager uses .local/share/keyrings for its storage, so it might help to
rm ~/.local/share/keyrings/login.keyringin order to force a recreation and get rid of the message.
Das Löschen des keyrings bringt jetzt nicht wirklich was denn offensichtlich sind darin diverse Zugangsdaten gespeichert wie z. B. die von meiner Nextcloud App. Also bleiben zwei Möglichkeiten: Entweder die Zugangsdaten bei jedem Login neu eingeben oder die erneute Speicherung in einem keyring den das System dann "Standard-keyring" nennt was dann wieder zum ursprünglichen Verhalten führt nämlich bei jedem Login die nochmalige Eingabe des Passwortes für diesen keyring.
Warum der keyring nicht mehr automatisch beim Login entsperrt wird wie früher, weiß der Teufel.
Im Netz gefunden/found this:
Quote:
edit /etc/pam.d/login
And add this at the bottom:
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
Vielleicht hilft es/maybe it helps
Nein, leider keine Änderung
eval "$(printf '\n' | gnome-keyring-daemon --replace --unlock --daemonize)"
Dies irgendwie in ein Autostart-Script packen und beim Login ausführen lassen und hoffen.
Is gnome-keyring running after you login.
ps aux | grep gnome-keyring
@eriefisher:
gnome-keyring is running:
ps aux | grep gnome-keyring
peter 2581 0.0 0.0 320668 9352 ? Sl 11:48 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
peter 2585 0.0 0.0 402952 11524 ? SLsl 11:48 0:00 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
@hendrikL:
dann werde ich mal ein Script suchen das beim Login abgearbeitet wird.
Nun, systemctl status gnome....
journalctl ...
Geben auch Informationen raus.
Wie man unter xfce4 den Keyring in den Griff bekommt, weiß ich wirklich nicht.
Ob man auch ohne den Keyring auskommt? Keine Ahnung.
Man könnte ihn ja mithilfe von systemctl --user stop/mask zum Schweigen bringen.
Noch etwas: Ich gebe jedes Mal nach dem Log-in ein Passwort ein, da ich KeePassXC als Passwortmanager nutze, und es stört mich nicht, da ich es so mit meinen Geräten synchronisieren kann.
What about gnome-keyring-pkcs11 and libpam-gnome-keyring? Are they installed? Not sure if it's relevent.
https://wiki.archlinux.org/title/GNOME/Keyring#Using_the_keyring
Yes they are installed.
@hendrikL:
Es ist jetzt kein Problem das Passwort nochmal einzugeben, mich interessiert halt warum das vorher ging und jetzt nicht mehr.
> Es ist jetzt kein Problem das Passwort nochmal einzugeben, mich interessiert halt warum das vorher ging und jetzt nicht mehr.
Is there still anyone dying to know what went wrong and how to fix it?
PS.: No one? Anyways: In post #8 hendrikL wrote:
> edit /etc/pam.d/login
> And add this at the bottom:
>
> auth optional pam_gnome_keyring.so
> session optional pam_gnome_keyring.so auto_start
And boy, was he close. The file to edit is actually /etc/pam.d/sddm from Debian package
sddm_0.21.0+git20260801.f62b7ba-3_amd64.deb. The vanilla /etc/pam.d/sddm is almost correct
except for line 31, where the following line must be added:
--- a/etc/pam.d/sddm 2026-08-23 15:05:53.000000000 +0200
+++ b/etc/pam.d/sddm 2026-09-04 22:06:54.131577353 +0200
@@ -30,6 +30,7 @@ session optional pam_keyinit.so
session required pam_limits.so
@include common-session
+session optional pam_gnome_keyring.so auto_start
@include common-password
The sddm helper binary responsible for starting the PAM module (and
in turn the gnome-keyring-daemon) can only get a grip on the login
password after the common-auth section succeeds and it's only purpose
is to decrypt the gnome keyring masterkey before the login password
is wiped and overwritten. The sddm daemon must keep the gnome daemon
alive once the masterkey is transfered to the daemon, which in turn forks
and execs the session gnome daemon after the common_session script.
Creating a new process of the gnome daemon before or after this tiny
window results in an empty password, which fails to decrypt the masterkey.
BTW: Your keyring should look like
$ ls -la ~/.local/share/keyrings
insgesamt 20
-rw------- 1 wt wt 601 4. Sep 16:59 login.keyring
-rw------- 1 wt wt 207 4. Sep 16:54 user.keystore
And upon login you can check an open keyring with
$ chromium --password-store=gnome-libsecret
Quote from: hendrikL on 2026/09/01, 07:21:48:
https://wiki.archlinux.org/title/GNOME/Keyring#Using_the_keyring
Quote: [...]
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of /etc/pam.d/login as mentioned below.
[...]
And I didn't read it carefully to the end....😎
The Debian bug tracker folks are still trapped in the process of deciding whom
to put the blame on:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142693>
And in the meantime we may leave the optional session line in its
interim position until it finds its final peace.
@Teriarch:
The lines in my sddm file looks as followed:
# Create a new session keyring.
session optional pam_keyinit.so force revoke
session required pam_limits.so
@include common-session
Do I have replace the line "session optional pam_keyinit.so force revoke" with "session optional pam_keyinit.so" or do I have add the line?
> Do I have replace the line "session optional pam_keyinit.so force revoke" with "session optional pam_keyinit.so" or do I have add the line?
You only have to add one single line to the already existing /etc/pam.d/sddm file (The unmodified file from the distributor).
The unmodified part reads:
# Create a new session keyring.
session optional pam_keyinit.so force revoke
session required pam_limits.so
@include common-session
@include common-password
# From the pam_env man pageand has to be replaced by
# Create a new session keyring.
session optional pam_keyinit.so force revoke
session required pam_limits.so
@include common-session
session optional pam_gnome_keyring.so auto_start
@include common-password
# From the pam_env man pageAs you can see only the line "session optional pam_gnome_keyring.so auto_start"
has been added at the right place. The other parts of this file stay the same.
Thank you very much Teriarch, it works. 🙂
> Thank you very much Teriarch, it works.
Well, it is never the last stone of a building, which deserves all the glory.
In the beginning I considered it a lost case thinking someone probably
messed up the code and is going to re-fix it with the next release. It was hendrikL
hinting at a possible configuration issue, that draw my attention back
to the problem. If anything it was my persistence to dig through all the different
authentication, display and wallet managers and their IPCs which placed
the final stone. There is one caveat though:
The sddm maintainer is not (yet) willing to accept the patch arguing that
it is libpam-gnome-keyring's responsibility (the gnome keyring PAM module)
to include the line into the common-session script. And he has a valid point
since that is exactly what KDE's favorite wallet manager kwallet does (hence
it works out of the box).
Until the dispute is settled you have to reapply the patch to the next sddm
release (don't include it into common-session, since that script will be
overwritten with each call of pam-auth-update).
Ich habe ein ähnliches Problem und zwar mit evolution mail. Ich werde ständig wieder nach den Passwörtern meiner Mailkonten gefragt. Mit seahorse kontrolliert, keyring war gesperrt. Passender Eintrag in der /etc/pam.d/lightdm war vorhanden, also einfach .local/share/keyrings/ umbenannt, das keyrings-Verzeichnis neu erstellt und rebootet. login.keyring und user.keystore wurden neu erstellt. In evolution auf Nachfrage die Passwörter eingegeben und mit seahorse kontrolliert ob die Einträge gemacht wurden, ja wurden sie. Trotzdem fragt evolution bei jedem Abruf von Mails wieder nach dem Passwort. Und das obwohl die keyrings entsperrt sind. Jemand das gleiche Verhalten beobachtet? Oder gar eine Lösung zur Hand?
Tipp an mich selber: Beim nächsten mal vorher suchen... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1147994
Ich benutze evolution nicht, trotzdem die Frage:
Hat sich das Problem mit Version 51.0-3 von gnome-keyring inzwischen erledigt?
P.S.:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1147994&pow_referer=#60>
behauptet:
QuoteOn Thu, 2026-09-17 at 19:42 +0100, Simon McVittie wrote:
> This is likely to be fixed in 51.0-2
Thanks, I can confirm updating from 51.0-1 to 51.0-3 fixed the issue
I'd reported in 1148156.
Antoine
Kann das jemand bestätigen?
Ich hab jetzt ein dist-upgrade laufen lassen, vorher gnome-keyring auf install zurück gestellt. Version 51.1-1 wurde mir aufs System gespielt.
Nach dem Reboot sieht es bis jetzt ganz gut aus, keine Fragen von Evolution nach Passwörtern.