Cannot login: could not update ICEauthority file .ICEauthority

From terminal

sudo apt-get --puge --reinstall install gdm

Solve...

From terminal

sudo apt-get --purge --reinstall install gdm

Solve...

something weird going on with lightdm then.

Thank you for your bug

Michael, could you have a look? I think it's something wrong in the update, I had to manually clean the .ICEauthority as well today there was a stalled on from yesterday which was breaking login (could access to the display due to it)

Just updated to 11.10 online today from a fresh 11.04. Was unable to log in - message "Cannot update ICEAuthority" was displayed.

I tried the "purge" suggestion (Marco, above) but this made no difference.

Will try again in a couple of weeks....

I have been unable to reproduce the .ICEauthority aspect of this bug. But I have been able to diagnose another problem with logging in that might be some user's actual problem: bug 824123.

Solution above worked for me. Thanks

I haven't gotten the .iCEauthority message in a bit, but I think I have been able to hit the same bug, just without the popup. I'm suspecting it's related to ecryptfs.

Notes:
 * It seems to be easier to reproduce after rebooting via Ctrl+Alt+Del
 * If after hitting this, I log into a VT, the problem goes away
 * If after hitting this, I log into a VT as a different user, I can see a recent .Xauthority file and .xsession-errors in /home/mike all by itself (this is the near-empty mount point over which ecryptfs gets put)

not sure if we are hijacking this bug wrongly but Barry opened bug #824594 about .Xauthority

As I also can't login through lightdm right now, I tried to follow this recipe as well. Merely removing .ICEauthority and .Xauthority doesn't seem to be sufficient for me; may it be that this is just a red herring, and that logging into the VT is a required step here to unlock ecryptfs?

What I did notice is that lightdm defaults to the wrong user for me (my "joe" test user), and already starts a PAM session for joe right at startup:

[+20.82s] DEBUG: Greeter start authentication for joe
[+20.82s] DEBUG: pam_start("lightdm", "joe") -> (0x7f8a440248f0, 0)

Changing to "martin" and trying to log in fails, I just get a black screen quickly, and then returns to lightdm. It does work if I switch between some more users, and then back to "martin". I need to examine this more closely, might very well be totally unrelated to this bug.

Adding ecryptfs-utils as "affected". I don't *think* the bug is there, as it seems to work with gdm, but having this bug show up under ecryptfs-utils should help with its discoverability.

At a quick glance, it looks to me like lightdm is trying to do something in the user's home directory before pam_ecryptfs finishes mounting it.

The strange thing to me is that before the encrypted home is mounted, $HOME is perm'd 500. So not even the owner should be able to write to it. This is by design to prevent you from accidentally writing cleartext data to your home.

Even though that's the case, the failed lightdm login process creates two files in the unmounted, read-only home:
 1) .dmrc
 2) .Xauthority

This seems to me like lightdm is doing some funny business as root, and then chowning this files back over to the user?

Okay, digging through the lightdm code a little, I'm looking at:

in src/display.c, the start_user_session() function does:
...
    g_debug ("Starting user session");
    user = pam_session_get_user (authentication);
    /* Load the users login settings (~/.dmrc) */
    dmrc_file = dmrc_load (user_get_name (user));
...

And in src/dmrc.c, the dmrc_load() function:
...
    /* Load from the user directory, if this fails (e.g. the user directory
     * is not yet mounted) then load from the cache */
    path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
    have_dmrc = g_key_file_load_from_file (dmrc_file, path, G_KEY_FILE_KEEP_COMMENTS, NULL);
    g_free (path);
...

Basically, if the user's home directory is not mounted, then something is *wrong*, and we shouldn't be proceeding yet. Lightdm should be blocking until the pam session start completes successfully.

Further down, this is just wrong:
...
    /* Update the users .dmrc */
    if (user)
    {
        path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
        g_file_set_contents (path, data, length, NULL);
        if (getuid () == 0 && chown (path, user_get_uid (user), user_get_gid (user)) < 0)
            g_warning ("Error setting ownership on %s: %s", path, strerror (errno));
        g_free (path);
    }
...

This is creating the ~/.dmrc file in a read-only $HOME directory as the root user, and then chowning it over to $USER. This leaves un-encrypted files in the user's home directory, which is very much undesirable, if a user is encrypting their home.

I haven't found a solution yet as I'm only looking at this a little bit while at a conference, but I thought I'd leave a few notes here :-)

My "starts pam session for other user early" apparently was a red herring. While that looks odd, according to the log it does complete the PAM session for "martin" successfully. So I confirm that I have the exact same bug here: I need to log into VT1 to unlock my ecryptfs home dir. I still need more than one try after that in lightdm, but that might be a followup race condition, and I'll debug it after fixing this initial issue.

We do wait to start the session until PAM authorizes us. But it's true that lightdm apparently likes to reach into the user's home directory before PAM authorizes us.

I tested by forcing lightdm to treat "/tmp" as the user's home directory and this problem went away. So what I think is happening is that lightdm opens a file in /home/user and that prevents the ecryptfs mount from happening...

This bug was fixed in the package lightdm - 0.9.3-0ubuntu4

---------------
lightdm (0.9.3-0ubuntu4) oneiric; urgency=low

  * Updated to current trunk, that's a candidate version version for the next
    update, it fixes those issues:
    - login doesn't work for ecryptfs users (lp: #823775, #824594)
    - "lightdm-gtk-greeter segfaults in get_user_iter when adding a new user"
    (lp: #822470)
    - fix fallback from org.freedesktop.Accounts to passwd format (lp: #817835)
    - empty autologin-user should not be passed to pam (lp: #817581)
  * debian/control.in:
    - build-depends on quilt, it's needed with source v1
    - don't build-depends on valac, vala is not used in the current version
  * debian/lightdm.install:
    - install the manpages as well
  * debian/lightdm.manpages:
    - dropped, it's installed by the upstream make install
  * debian/rules:
    - use the quilt rule
  * debian/source/format:
    - use source v1, it works better with vcs workflows
 -- Sebastien Bacher <email address hidden> Thu, 18 Aug 2011 15:29:42 +0200

Hmm, was there a regression here? I have lightdm 0.9.7-0ubuntu1, and see the exact the same issue with "could not update ICEauthority file .ICEauthority". User has the home directory crypted with ecryptfs, which stays unencrypted, which is why the error is shown.

Tomasz, do you have autologin turned on or "login without a password"? Those are incompatible with ecryptfs and I just uploaded a new gnome-control-center that will prevent you from using such options with it.

Was okay since yesterdays updates to the system. I got the "could not update ice-authority" even when the user was login'ed at another VT before. Autologin is not activated here, no encrypted user can login to the gui but on VT to their home.

Tonight I upgraded from 11.04 to 11.10, and now I can't login under my user, but can login in VT, and can login in lightDM to guest session.
I have autologin turned on 11.04

I have the home directory crypted with ecryptfs too

naxHO, you shouldn't have both autologin and ecryptfs enabled. You'll have to turn off autologin.

And how can I do this now?

Try editing /etc/lightdm/lightdm.conf and removing the autologin-user line.

there no such line in config

Robert, do you know why someone would be autologging in without that being set in /etc/lightdm/lightdm.conf?

no! I have autologin in GDM in ubuntu 11.04.
Now I can't login in lightDM under user with crypted home directory

I've delete file .Xauthority from home directory and now can login

Have the same thing on the work laptop. After delete .Xauthority I can login

Well, made the mistake to go for precise.
So nothing works at all. System hangs. Kernel Panic. Other bugs..

Well, had that issue also. Deleting, changing the Attributes of that .Xauthority file did not fix a thing.

My workaround: Purge gdm. Not lightdm. Remove the leftover files manually.. ( in /etc/ and /var/lib/gdm? ) Purge and reinstall itself wasn't enough. Then reinstall via aptitude. Works again then.

Downside of this. Now i have to start Xorg manually. Start lightdm or gdm manually. How can i restore it to be started automatically?

The issue got marked as a duplicate somewhere else so i joined this bug. But actually i don't have ecryptfs and the workaround comment #9 suggested was not anywhere near possible or a remedy. This was more likely a upgrade permission messup somewhere within gdm / lightdm.

I believe that this bug has been solved long ago with a lightdm upload. Marking the ecryptfs-utils task as fix released as this issue seems to be fixed.