[regression-release] Keyring not unlocked on login anymore in Lucid

Bug #529338 reported by nobody on 2010-02-28
This bug affects 47 people
Affects Status Importance Assigned to Milestone
gnome-desktop (Ubuntu)
gnome-keyring (Ubuntu)
seahorse (Ubuntu)

Bug Description

The keyring is no longer automatically unlocked on login anymore in Lucid; on log in I am prompted for my password again so the WPA key can be obtained. I can't screenshot that dialog, it seems to be modal or something similar. Also, the grammar in the heading of that dialog is wrong (your password <for to> unlock).

description: updated

I confirm, I have the same issue: keyring is no longer automatically unlocked on login.

affects: ubuntu → gnome-keyring (Ubuntu)
Juanma (jm-mico) wrote :

It also affects to me. Beta1 installed on top of Karmic.
Linux dell 2.6.32-18-generic-pae #27-Ubuntu SMP Fri Mar 26 21:21:16 UTC 2010 i686 GNU/Linux

Updated as of today.

Tom Louwrier (tom-louwrier) wrote :

Same here, although I had to use a workaround to get in th GUI (recovery mode > resume normal boot > login > startx) After the desktop appeared I was asked for my password in order to unlock the keyring.
(Lucid amd64, updated twice a day, regressed a lot over the last week, now foobar.)


Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Leo (leorolla) wrote :

Also affects me.

Architecture: i386
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
Package: seahorse 2.30.0-0ubuntu2
PackageArchitecture: i386
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic
Tags: lucid lucid
Uname: Linux 2.6.32-19-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

tags: added: apport-collected

apport information

Leo (leorolla) on 2010-04-29
Changed in seahorse (Ubuntu):
status: New → Confirmed
Changed in gnome-desktop (Ubuntu):
status: New → Confirmed

I have this bug, and "resolved" it by changing the keyring password to my user account password. The problem is, I log in most often with fingerprint-based authentication, so there is not password to ask about. In the past I would be asked to unlock my keyring, now this down not happen.

Patryk Szalanski (musefan) wrote :

I am also affected by this issue, since I log in by using fingerprint authentication. Why doesn't the keyring daemon ask for a password when it is not unlocked? That is clearly a bug since Lucid for me.

uname -a
Linux p-ubuntu 2.6.33-020633-generic #020633 SMP Thu Feb 25 10:10:03 UTC 2010 x86_64 GNU/Linux

SarahK (katz-sarah) wrote :

I also use a fingerprint reader, and am affected by this issue. Even after removing the keyring password it is not unlocked on login when using a fingerprint as authentication.

Clean install of Lucid, with a preexisting /home directory on a second partition.
Linux gremlin 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux

RobertDahlström (cinnarob) wrote :

The same thing started happening to me after the upgrade containing kernel 2.6.32. Before that it worked as before.

dr.spock (dr.spock) wrote :

Same here.

After upgrading to Lucid, I'm not asked to unlock my keyring if I log in using fingerprint, as happened before.

If I log in using username and password, I'm asked to unlock it, even though my keyring and login passwords are the same.

Harald (haraldboehmecke) wrote :

same as dr.spock with Lenovo T61 and thinkfinger.

Leo (leorolla) on 2010-05-17
tags: added: regression-release
summary: - Keyring not unlocked on login anymore in Lucid
+ [regression-release] Keyring not unlocked on login anymore in Lucid
ikkarus (bene-rogerio) wrote :

my seahorse and mysql workbench show errors when trying connect to gnome-keyring-daemon.

atterdag (valdemar-lemche) wrote :

Same problem

1) I recreated my account
2) When logging in with username and password the keyring is unlocked, gwibber and Network Manager works are able to read password from the keyring
3) I removed the password from the keyring, and after I log in again using username and password, gwibber and Network Manager are still able to properly read the passwords from my keyring
4) I create a .thinkfinger.bir and logs in using my finger, and gwibber and Network Manager are _not_ able to read the password from the keyring

The expected result of step 4 was that gwibber and Network Manager would in fact be able to read the keyring, and until a about a week ago this worked like a charm.

Is this really a bug or MUST you login with username and password to at all use the keyring?

1) Network Manager: apply the wireless profile to all users. This takes the local keyring out of the equation.
2) gwibber: just run "gnome-keyring-daemon -d" from a command line before starting gwibber

J Bruni (jbruni) wrote :

Can anyone tell me if the following is related to this bug?


Thank you.

Saša Teković (hseagle2015) wrote :


I'm having trouble with the same problem. I use Lenovo Thinkpad x300 and when I log in using fingerprint reader (thinkfinger), I don't get asked for password to unlock my keyring, therefore nm-applet is running in the background but without the icon on the panel, so I'm not able to use it to connect to any network.

If I kill the nm-applet process and restart it manually in the Terminal, I get the following error:


** Message: secret service operation failed: Activation of org.freedesktop.secrets timed out

** Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.


I noticed that, if i kill gnome-keyring-daemon and nm-applet processes and just run "nm-applet --sm-disable &" in the Terminal, I get nm-applet running and I'm asked to enter my keyring password.

Just like it was already mentioned before (couple of comments up), this problem arises only when logging into the system is done by using fingerprint reader. If I log in by entering my password, everything works as it should.

Martin Bernát (martin-bernat) wrote :

Same thing here (Lucid, kernel 2.6.32-22) after I installed thinkfinger.

nm-applet, rhythmbox, empathy stopped working, some other apps started to behave weird.

After reading this bug report I started to log in using my password and everything seems to work as it should.
Hope this will be fixed soon.

Sebastien Bacher (seb128) wrote :

gnome-desktop is a library handling desktop entries and xrandr events and the "about GNOME" dialog, not a bug there

Changed in gnome-desktop (Ubuntu):
importance: Undecided → Low
status: Confirmed → Invalid
Sebastien Bacher (seb128) wrote :

is the issue there specific to fingerprint login or is the bug collection different issues?

Leo (leorolla) wrote :

With normal login as well.

Now it seems that changing the login password through the Users and Gruops GUI is not changing the keyring's password accordingly.

pvh (pvh-webbedfeet) wrote :

@Sebastien: This seems to be triggered by fingerprint login (of different types - I use libpam-fprint and others use thinkfinger) but the underlying cause seems to not be the fingerprint login but rather the changed behaviour in gnome-keyring when it can't authenticate with the login password. In the past after login I was asked to unlock my keyring. Now it only seems to unlock if I log in with a login password that is the same as my keyring password.

Tom Moore (mooret01) wrote :

This affects just normal logins. It is not specific to any fingerprint readers.

Andy Cooling (andycooling) wrote :

Have had this problem for a while, had auto log on, problem goes when I use the log on page and comes back with auto log on, may explain why it affects finger print readers too.

Erick Brunzell (lbsolost) wrote :

I encountered this bug while performing some totally unrelated testing that involved the installation of some proposed updates in Lucid, you can read the whole story in comment #71 of bug #576724.

I assume that it was mere coincidence that this bug appeared at that time but thought it deserved a mention.

Erick Brunzell (lbsolost) wrote :

I've also now encountered this in Maverick, more info in bug #576724 (comments #71 and #72, although I think it's largely unrelated. I'm trying to find the "trigger" or any commonality.

Erick Brunzell (lbsolost) wrote :

I've been looking for commonalities regarding this bug and I wonder if folks would please tell us what file system they were using?

Please read this thread:


Does it apply to you?

SarahK (katz-sarah) wrote :

I'm running a dual boot (single drive) NTFS Vista/ext3 Ubuntu system. Bug 576724 does not apply to me, Vista boots just fine.

Model: ATA WDC WD800BEVS-08 (scsi)
Disk /dev/sda: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 7313MB 7312MB primary ntfs
 2 7313MB 52.3GB 45.0GB primary ntfs boot
 3 52.3GB 62.3GB 9994MB primary ext3
 4 62.3GB 80.0GB 17.7GB extended
 6 62.3GB 78.0GB 15.7GB logical ext3
 5 78.0GB 80.0GB 1997MB logical linux-swap(v1)

I suspect this bug is completely unrelated to file system. For me the bug was triggered by adding the line "auth sufficient pam_fprint.so" to /etc/pam.d/common-auth to allow a fingerprint login. Reverting common-auth to the default version and using my password to log in allowed the keyring to unlock. Take a look at the bug referenced by J Bruni above and see what you think.

Erick Brunzell (lbsolost) wrote :

I'm not using a fingerprint reader. On this machine I am the only user so there is only one password.

I posted a screenshot here:


I only get that if I'm using auto-login. If I log in using my password all is fine.

I first encountered this behavior in Lucid after applying the following proposed updates:

app-install-data-partner (12.10.04) to
dpkg ( to
empathy ( to 2.30.2-0ubuntu1
empathy-common ( to 2.30.2-0ubuntu1
grub-common (1.98-1ubuntu6) to 1.98-1ubuntu7
grub-pc (1.98-1ubuntu6) to 1.98-1ubuntu7
libatk1.0-0 (1.30.0-0ubuntu2) to 1.30.0-0ubuntu2.1
libatk1.0-data (1.30.0-0ubuntu2) to 1.30.0-0ubuntu2.1
libdbusmenu-glib1 (0.2.9-0ubuntu3) to 0.2.9-0ubuntu3.1
libdbusmenu-gtk1 (0.2.9-0ubuntu3) to 0.2.9-0ubuntu3.1
nautilus-sendto-empathy ( to 2.30.2-0ubuntu1
update-manager (1:0.134.9) to 1:0.134.10
update-manager-core (1:0.134.9) to 1:0.134.10

That was somewhat of an error on my part as I'd intended to only upgrade 'grub-pc' and 'grub-common', but I ended up with the same behavior in Maverick after upgrading the 'grub' packages. I'm unsure that was the actual trigger but it may be???? However even purging/reverting these packages does not revert to the "unbroken" state.

Strangely I was not able to duplicate this behavior with test installs of Lucid and Maverick on my secondary drive and ATM it appears that I can duplicate this behavior if either Lucid or Maverick are installed using ext3, but NOT if I use ext4.

I do however need to perform a few more test installs to be certain and, due to totally unrelated time constraints, that may take a few days.

That's why I wonder if others effected by this are all using ext3?

Or has anyone seen this if using ext4?

Something else I've found while testing for this behavior is that opening any password protected gui (eg: synaptic, gufw, gparted, etc) will always produce this behavior if the problem is present. That is I'll first have to enter my password "to unlock keyring" and then also on the expected screen to "perform administrative tasks". Of course it appears only once after each reboot.

Leo (leorolla) wrote :

As far as I can remember, when I had this issue I was using ext4, and no dual boot.
Also, as far as I can remember, I got rid of this issue by creating a new user account.

It could be related to the files inside the user's home folder.

It's just a guess, but worth trying:
Those who still experience this problem, could you create a new user account, without fingerprint and without autologin, and see if this problem persists?
What's the name of the default keyring? Mine is called "Passwords: login".

Martin Nemec (spocky) wrote :

I'm also affected by his bug!
using a clean lucid with all updates applied on an ext4 file system.
Please give me direction how i can support you in finding the bug

Shaji N V (nvshaji) wrote :

I had this problem - but it got resolved in the following fashion.

When it was asking for a keyring password - Click on Details and then tick "Automatically unlock this key ring when I am logged in" toggle. And now it does not ask for a password.

I'm affected by the same issue. Don't make use of any fingerprint authentication, only old username/password pairs on GDM.

System: Ubuntu 10.10
dpkg -l | grep seahorse
ii libcryptui0 2.32.0-0ubuntu1 the UI library for DBUS functions exported by seahorse
ii seahorse 2.32.0-0ubuntu1 GNOME front end for GnuPG

1.) Log in on GDM using username/password credentials;
2.) NetworkManager tries to authenticate against wifi router;
3.) Keyring unlock password is asked (although I checked to automatically unlock the keyring many times);

steve taylor (stevemail) wrote :

Recent post #142383

Ubuntu 10.10 desktop key ring log-in twice.

Having this 'double log-in' problem at start-up I was looking in 'Passwords and Encryption Keys' where
I found that 'Desktop Couch Authentication' is listed twice.

Is this as it should be and/or could this cause the need to log-in twice?

If this is the culprit, is there a way to safely remove one of these entries?

I want to list this as low priority but if there is some explanation I would be interested
as both my computers have this problem. Also I don't want to mess up key ring as I don't
exactly understand how it works, I can put up with double log-ins better than a whacked OS.

I have read threads but they either go round in a circle or miss the point.

note: So this 'bug' has a history, I wonder how many have the same problem but don't report as it's just a bit irritating.
Maybe this should be a new category called 'glitch' as 'bug' might be a bit heavy for a minor inconvenience.
Anywhichway I still think ubuntu is the awesome.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers