LDAP user with automounted nfs homedir cannot login

Bug #870874 reported by Heiko Harders
334
This bug affects 61 people
Affects Status Importance Assigned to Milestone
at-spi2-core (Ubuntu)
Confirmed
High
Unassigned

Bug Description

After installing Ubuntu (Oneiric, development branch) I followed two guides to setup LDAP authentication and automounting of home directories using autofs-ldap. This setup was working properly for older Ubuntu releases (just to be sure I also tried with a fresh, up to date 11.04 installation).

The following steps were executed to setup LDAP authentication:
https://help.ubuntu.com/11.04/serverguide/C/openldap-server.html (section: LDAP Authentication)

These steps were executed to setup Autofs-ldap:
https://help.ubuntu.com/community/AutofsLDAP

LDAP users properly login from the terminal (Ctrl-Alt-F1), in that case they can browse their automounted homedirs etc.

When I try to login using LightDM the user seems to be logged in properly; the login widget disappears from the screen but other than that nothing is happening (the login screen background is still visible, but the login widget is gone). I still can move the mouse pointer but the user is not logged on. When taking a look at the user's .xsession-errors file there is not much to see, nothing that seems worrying to me. I can't find anything that obviously looks like an error in /var/log/*.

I tried several things:
- removed all files/directories starting with a . (dot) in the user's home directory
- using LightDM and the default Ubuntu window manager
- using LightDM with Gnome
- using GDM with Gnome

In all cases the same behavior was observed.
Logging in with a local user works like a charm.

This is what /var/log/lightdm/lightdm.log says:
[+2.83s] DEBUG: Read 8 bytes from greeter
[+2.83s] DEBUG: Read 15 bytes from greeter
[+2.83s] DEBUG: Greeter start authentication for test_user
[+2.83s] DEBUG: pam_authenticate(0x169e340, 0) -> 10 (User not known to the underlying authentication module)
[+2.83s] DEBUG: pam_start("lightdm", "test_user") -> (0x7f1ae4011570, 0)
[+2.85s] DEBUG: Prompt greeter with 1 message(s)
[+2.85s] DEBUG: Wrote 45 bytes to greeter
[+16.20s] DEBUG: Read 8 bytes from greeter
[+16.20s] DEBUG: Read 16 bytes from greeter
[+16.20s] DEBUG: Continue authentication
[+16.22s] DEBUG: pam_authenticate(0x7f1ae4011570, 0) -> 0 (Success)
[+16.22s] DEBUG: pam_acct_mgmt(0x7f1ae4011570, 0) -> 0 (Success)
[+16.22s] DEBUG: Authenticate result for user test_user: Success
[+16.22s] DEBUG: User test_user authorized
[+16.22s] DEBUG: Wrote 27 bytes to greeter
[+16.24s] DEBUG: Read 8 bytes from greeter
[+16.24s] DEBUG: Read 15 bytes from greeter
[+16.24s] DEBUG: Greeter requests session gnome-shell
[+16.25s] DEBUG: Stopping greeter
[+16.25s] DEBUG: Dropping privileges to uid 104
[+16.25s] DEBUG: Removing session authority from /var/lib/lightdm/.Xauthority
[+16.28s] DEBUG: Restoring privileges
[+16.28s] DEBUG: Sending signal 15 to process 7950
[+16.28s] DEBUG: Process 7950 exited with return value 0
[+16.28s] DEBUG: pam_close_session(0x167f300) -> 0 (Success)
[+16.28s] DEBUG: pam_setcred(0x167f300, PAM_DELETE_CRED) -> 0 (Success)
[+16.28s] DEBUG: pam_end(0x167f300) -> 0
[+16.28s] DEBUG: Ending ConsoleKit session 6e3a694924188906d4093c6702696be1-1318095483.743254-1770205889
[+16.31s] DEBUG: Greeter quit
[+16.31s] DEBUG: Starting user session
[+16.38s] DEBUG: Dropping privileges to uid 1049
[+16.38s] DEBUG: Writing /srv/home/test_user/.dmrc
[+17.48s] DEBUG: Restoring privileges
[+17.51s] DEBUG: Starting session gnome-shell as user test_user logging to /srv/home/test_user/.xsession-errors
[+17.51s] DEBUG: Launching session
[+17.51s] DEBUG: pam_set_item(0x7f1ae4011570, 3, ":0") -> 0 (Success)
[+17.55s] DEBUG: pam_open_session(0x7f1ae4011570, 0) -> 0 (Success)
[+17.58s] DEBUG: Opened ConsoleKit session 6e3a694924188906d4093c6702696be1-1318095500.694488-13642418
[+17.58s] DEBUG: Dropping privileges to uid 1049
[+17.58s] DEBUG: Adding session authority to /srv/home/test_user/.Xauthority
[+17.82s] DEBUG: Restoring privileges
[+17.82s] DEBUG: Launching process 8053: /usr/sbin/lightdm-session 'gnome-session --session=gnome'
[+17.82s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+17.92s] DEBUG: pam_setcred(0x7f1ae4011570, PAM_ESTABLISH_CRED) -> 0 (Success)
[+17.92s] DEBUG: PAM returns environment 'GNOME_KEYRING_CONTROL=/tmp/keyring-6wgIZV GNOME_KEYRING_PID=8044 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_US.UTF-8'

The user's .xsession_errors:
Running X session wrapper
Loading profile from /etc/profile
Loading resource: /etc/X11/Xresources/x11-common
Loading X session script /etc/X11/Xsession.d/20x11-common_process-args
Loading X session script /etc/X11/Xsession.d/30x11-common_xresources
Loading X session script /etc/X11/Xsession.d/40x11-common_xsessionrc
Loading X session script /etc/X11/Xsession.d/50_check_unity_support
Loading X session script /etc/X11/Xsession.d/50x11-common_determine-startup
Loading X session script /etc/X11/Xsession.d/52libcanberra-gtk3-module_add-to-gtk-modules
Loading X session script /etc/X11/Xsession.d/52libcanberra-gtk-module_add-to-gtk-modules
Loading X session script /etc/X11/Xsession.d/55gnome-session_gnomerc
Loading X session script /etc/X11/Xsession.d/60x11-common_localhost
Loading X session script /etc/X11/Xsession.d/60x11-common_xdg_path
Loading X session script /etc/X11/Xsession.d/60xdg-user-dirs-update
Loading X session script /etc/X11/Xsession.d/65compiz_profile-on-session
Loading X session script /etc/X11/Xsession.d/70gconfd_path-on-session
Loading X session script /etc/X11/Xsession.d/75dbus_dbus-launch
Loading X session script /etc/X11/Xsession.d/80appmenu
Loading X session script /etc/X11/Xsession.d/80appmenu-gtk3
Loading X session script /etc/X11/Xsession.d/80im-switch
Setting IM through im-switch for locale=en_US.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
Loading X session script /etc/X11/Xsession.d/90consolekit
Loading X session script /etc/X11/Xsession.d/90qt-a11y
((EOF, thats all))

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lightdm 1.0.1-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
Date: Sat Oct 8 19:40:24 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110921.2)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Heiko Harders (heiko-harders) wrote :
Revision history for this message
Heiko Harders (heiko-harders) wrote :

It seems the system is hanging at:
`gsettings get org.gnome.desktop.interface toolkit-accessiblity'

Once I did a `killall gsettings' the ldap user logged in properly.

Revision history for this message
Heiko Harders (heiko-harders) wrote :

I can confirm this on two machines. The command in the above post contains a typo, the command below is the one at which the login process hangs:

`gsettings get org.gnome.desktop.interface toolkit-accessibility'

According to `ps aux' the process is in state `Sl'. When I kill that single process (no need to do a killall like I mentioned in the previous post) the login process continues and the user logs in nicely. Logging in with a local account always works fine. Logging in with LDAP authentication and Autofs mounted homedirs causes always a hang on this process.

I tried running the same command from the command line after being logged in with both a local account and an ldap authenticated account. In both cases it returns `false'.

Revision history for this message
Heiko Harders (heiko-harders) wrote :

I guess this is not a lightdm issue, so changing the package to Xorg.

affects: lightdm (Ubuntu) → xorg (Ubuntu)
Revision history for this message
Heiko Harders (heiko-harders) wrote :

Probably final comment from me, I found a workaround that "solves" the problem for me.
If you don't need QT Accessibility:

Edit `/etc/X11/Xsession.d/90qt-a11y', put a `#' in front of all lines:

# -*- sh -*-
# Xsession.d script to set the QT_ACCESSIBILITY env variable when accessibility
# is enabled.
#
# This file is sourced by Xsession(5), not executed.

#if [ -x "/usr/bin/gsettings" ]; then
# a11y_enabled=$(gsettings get org.gnome.desktop.interface toolkit-accessibility)
# if "$a11y_enabled" = "true" ]; then
# export QT_ACCESSIBILITY=1
# fi
#fi

This work around might break with updates.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you gdb or strace to see how that comment is hanging? gsettings shouldn't hang ever...

affects: xorg (Ubuntu) → at-spi2-core (Ubuntu)
tags: added: a11y
Revision history for this message
Heiko Harders (heiko-harders) wrote :

Here is a strace. Couldn't make it hang while stracing though:
http://pastebin.com/mQ6Zgja1

Not sure how to produce anything useful with gdb, if you have any suggestions I'm happy to try. I could connect with gdb to the hanging program, would that be of any use? And what kind of information would you like to see from gdb in that case?

Revision history for this message
Ulf Mehlig (umehlig) wrote :

I see a similar problem here after upgrading from a working 10.04 setup with nfs mounted home directories and ldap user database and kerberos authentification. Weh using lightdm, the systems seems to hang. When starting gdm, the login is taking place but the gnome/unity sessions are not started. When the user is logged in on the console (Alt + F1 etc.) and sets the display variable correctly, it is possible to start gnome-session manually.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in at-spi2-core (Ubuntu):
status: New → Confirmed
Revision history for this message
Ulf Mehlig (umehlig) wrote :

With the workaround from comment #5, lightdm seems to accept the login but then returns to the login screen. With gdm, login works.

Revision history for this message
Lennart Karssen (l.c.karssen) wrote :

I have an LDAP setup also, with home directories over NFS, but no automounting or Kerberos. Like Heiko in post #2, killing gsettings from a tty helps. After that, Lightdm logs in properly.

This was on a fresh install of Ubuntu 11.10, I also moved folders like .compiz, .local, .config to a backup location before logging in the first time. Later I tried to copy the subdirectories for some applications back to their original location.

Revision history for this message
Lennart Karssen (l.c.karssen) wrote :

A quick note: the workaround in #5 works for me, Lightdm logs me in without delay.

Revision history for this message
Sakari Maaranen (sam-iki) wrote :

I have Oneiric LDAP authentication with local home directories. No NFS, no autofs.

Gnome LDAP user login hangs every time with process: "gsettings get org.gnome.desktop.interface toolkit-accessiblity"

Killing that single process with signal 1 (kill -1 PID) from TTY lets the Gnome session login continue normally, i.e. same solution as in #2 works.

Local root Gnome login works normally.

Revision history for this message
Edgar (edgar-nl) wrote :

I have an LDAP setup with a clean Ubuntu Desktop 11.10 Client. and #5 didn't work for me.
With and without the same as #10:
'lightdm seems to accept the login but then returns to the login screen.'

With GDM i don't know... (and don't know how to test)

Revision history for this message
Claudio Bernardini (claudiob) wrote :

Same for me as per comment #14 (with the addition of NFS automounted homedirs).

If I shutdown lightdm:
  sudo /etc/init.d/lightdm stop
and start gdm:
  sudo /etc/init.d/gdm start
then I can login to the desktop.

To avoid doing this every time I startup my pc I had to change default manager to gdm with:
  sudo dpkg-reconfigure lightdm

Revision history for this message
Mark A. Ziesemer (ziesemer) wrote :

I also have an LDAP setup on a clean Ubuntu 11.10 install - but with local homedirs - and am also experiencing this issue.

The "gsettings get" is also hanging with gdm - so switching to gdm from lightdm is not a surefire fix for this issue, either.

Disabling the 90qt-ally script immediately fixed my issue. Quick tip on this - rather than editing and commenting-out the entire file, it can be disabled by just prefixing it with a non-# - e.g. "cd /etc/X11/Xsession.d && mv 90qt-a11y x90qt-a11y".

Revision history for this message
Rob ten Hove (robth) wrote :

I also use LDAP and automounted home dirs, and login via LightDM does not work. With a local user, it does work.
Logging in with an LDAP user via Ctrl-Alt-F1 works like a charm.

I don't have any problems with the /etc/X11/Xsession.d/90qt-a11y script so I didn't touch it.

Solution for me was to switch to GDM instead of LightDM.

"sudo dpkg-reconfigure lightdm", choose "gdm".

Revision history for this message
Andreas Müller (andy-mueller-zuhause) wrote :

Same here, but no difference using lightdm, gdm or even kdm. Configuration: ldap users, home directories mounted via nfs. Local users can login graphically, ldap users can login on a terminal without any problem, but not via X. After login, the logtin dialog disappears and the mouse cursor can be moved, but nothing else happens.

Revision history for this message
Benjamin A. (benjamin-aupetit) wrote :

Same config as #18. And same problem, switching between dm's didn't help. Although using #5 solved the problem, I am looking for a more long-term solution.

Note: logging a LDAP user through the terminal (Ctrl-Alt-F1~6) and then starting x manually works fine. Thus I presume the problem emmerge from the dm. (X being started with : xstart -e 'gnome-session --session=ubuntu' and this works with other types of session (gnome, kde ...)

Revision history for this message
Luke J Militello (kilahurtz) wrote :

I can also confirm the presence of this bug. I have been running the same LDAP and NFS servers/setups since 2008. My LDAP and NFS servers are running 8.04 and I have never had this problem until using 11.10 as a client. This is also a fresh install and the posted workaround works; however, I chose to just move the script out of the directory altogether and save a backup copy in root's home directory for the time being. I believe this bug should be marked as medium to high importance as it hinders the ability for any production level networks to function properly that require the use of LDAP and NFS for roaming profiles. Thus prohibiting the use of the latest Ubuntu for use in corporate networks.

Revision history for this message
Luke J Militello (kilahurtz) wrote :

This is also present in Linux Mint 12. Same workaround can be applied as well.

Revision history for this message
Daniel Lage (dnlage) wrote :

I also can confirm the presence of this bug on my work. I am administer an network with more 100 computers, all then using Ubuntu, 9 and 10. Also using NFS and LDAP for personal profiles. On my tests for upgrading this bug persist. I also think that we have to marked this bug to high. I am from Brasil, and i believe that are a lot of networks working with ubuntu more NFS and LDAP.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

This bug is really serious and I would also suggest to put it as high.
I never faced so many troubles as with this 11.10 realease and this is a blocker for any upgrade on our network clients as we run on NFS remote mounted homedirs with autofs-ldap.

Revision history for this message
Sakari Maaranen (sam-iki) wrote :

I also think this bug should get HIGH priority. LDAP is essential for so many deployments.

I also recommend testing that "sudo", "su -" and "sudo su -" work as expected from LDAP-only user accounts. I'm experiencing this bug with LDAP user accounts, but I worked around it using instructions found in this bug report. However, there's an additional problem probably related to this, which doesn't go away:

I have a user account "johndoe" that only exists in LDAP. That user account belongs to local groups "sudo" and "admin" as specified in /etc/group.

 ~# getent passwd johndoe
 johndoe:x:10003:10003:John Doe:/home/johndoe:/bin/bash

 ~# getent group sudo
 sudo:x:27:johndoe

 ~# getent group admin
 admin:x:118:johndoe

 ~# cat /etc/sudoers | grep '%[admin|sudo]'
 %admin ALL=(ALL) ALL
 %sudo ALL=(ALL:ALL) ALL

I have NOT set ignore_local_sudoers so it should work with LDAP and local /etc/sudoers file.
But sudo is not working. What happens instead is:

 johndoe@host:~$ sudo su
 sudo: setreuid(ROOT_UID, user_uid): Operation not permitted
 johndoe@host:~$ su -
 Password: ***CORRECT*PASSWORD***
 su: Authentication failure
 johndoe@host:~$ sudo cat /etc/group
 sudo: setreuid(ROOT_UID, user_uid): Operation not permitted

These problems may be related, so I recommend checking sudo and su as well when investigating and testing this bug.

Revision history for this message
Michael Stockenhuber (michael-st) wrote :

Same problem here. I am running ldap login for years on four debian servers and one debian and one ubuntu desktop ( the bug does not appear in debian stable). I use local home directories and the problem occurs with and without NFS and CIFS mounts.
I agree this is a serious bug. I was able to workaround using suggestion in #16.
I tried kdm and also to start a kde shell from either kdm or gdm, same problem. The username of the ldap users does not appear in either gdm or kdm, even with the workaround. It looks the user is not known to the display manager, i.e., it does not retrieve from ldap? Login to a shell works perfect.
It would be great if this bug could be assigned to someone who can look into it.
Cheers
Michael

Revision history for this message
Robert Maynord (r58eft) wrote :

Same problem here. I have been experimenting with Kubuntu 11.10, and there is not file to fix as mentioned in #5. (By the way, I am running 11.10 on both the server and the client). I tried LXDE & LXDM to see if there was any change. Interesting: I can sometimes partially log in, but if more than one account is open they will both freeze. Could all this be related to this bug: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/891825

Has anyone tried an nfs downgrade to a previous version?

Revision history for this message
Stephan Schöffel (stephan-schoeffel) wrote :

I am facing the same problem now at our computer-labs at university. Mounted NFS homedirs and LDAP authentication. A co-worker tried a different approach using SLIM as login manager. This let's LDAP users login and use unity properly. Unfortunately, it screws up local accounts. Additionally, the shutdown/reboot widget does not work anymore. Users can only logout with these, but not stop/reboot the machine. One more thing: if the screen becomes locked, users cannot unlock it via LDAP.

Revision history for this message
Sakari Maaranen (sam-iki) wrote :

This bug seems to have stuck behind a "Low" urgency package "at-spi2-core". Do you think this bug is reported behind the right package?

While it's true that the problem seems to appear with a reference to QT accessibility features, which may have lower priority, the real use case where this occurs is LDAP authentication that IMHO should have a higher priority. Surprisingly, also the following packages seem to have "Low" urgency: ldap-auth-client, libnss-ldap, libpam-ldap

What is the correct procedure to have Ubuntu reconsider the urgency of LDAP authentication packages and related issues?

Revision history for this message
giangiammy (giangiammy) wrote :

Hi,

This bug also affects the 12.04 alpha2 release

Revision history for this message
Denis Brækhus (denisb) wrote :

As #29 says, this bug is evident also in the 12.04 builds, and even the workaround suggested by #5 does not work for me.
It is pretty critical to get this working, would be nice with just a little activity on this bug at least.

Revision history for this message
Tim K (kelletim) wrote :

This is killing us here as well, nfs mounted homes in 11.10.

Revision history for this message
Tim K (kelletim) wrote :

this should be "grave"

Revision history for this message
Ian Morris (ipm) wrote :

Re: #31, since applying https://launchpad.net/ubuntu/oneiric/+source/at-spi2-core/2.2.2-0ubuntu1.2 from oneiric-updates published on 2012-02-16, I've not experienced the problem -- are you applying changes from -updates?

Revision history for this message
Rob ten Hove (robth) wrote :

Confirmed #33: it works here too.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

It works here too now.

Revision history for this message
Shawn Haggett (podge-9) wrote :
Download full text (5.5 KiB)

I'm guessing the change linked to in #33 that fixes this is:
  * Remove 90qt-a11y: Qt accessibility is not stable enough in Oneiric to be
    enabled by default for all applications. A patch for unity-2d specifically
    enables accessibility for it so that the desktop remains accessible.
    (LP: #877358)
And the next change:
  * Actually remove 90qt-a11y if it is already installed.

I just upgraded to 12.04 and at-spi2-core version 2.4.0-1 and the 90qt-a11y file is back and exhibiting the same symptoms. So far I have found (always using an LDAP/Kerberos user with a Kerberised NFS4 home directory):

Logging into the virtual console, and running the gsettings command from #3 and it prints "false" and hangs.
Running gsettings under strace on the virtual console, it exits fine.
Running gsettings from a terminal in X, it exits fine.

Next I ran an instance at the virtual console and left it hung, then (after fetching the debug symbols) attached to the hung process with gdb. I find there's two threads:
(gdb) thread find .*
Thread 2 has target name 'dconf worker'
Thread 2 has target id 'Thread 0x7f51717b5700 (LWP 22479)'
Thread 1 has target name 'gsettings'
Thread 1 has target id 'Thread 0x7f51779fc7c0 (LWP 22478)'

Thread 1 (which is the one gdb chooses when you attach), shows a backtrace of:
(gdb) bt
#0 __unregister_atfork (dso_handle=<optimised out>)
    at ../nptl/sysdeps/unix/sysv/linux/unregister-atfork.c:117
#1 0x00007f5174fe8716 in __do_global_dtors_aux () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#2 0x00007ffffa9b0430 in ?? ()
#3 0x00007ffffa9b0600 in ?? ()
#4 0x00007f5174ff5371 in _fini () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#5 0x000000000000002c in ?? ()
#6 0x00007f517780992d in _dl_fini () at dl-fini.c:259
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 shows a backtrace of:
(gdb) bt
#0 0x00007f517675e89c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f517675a065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f5176759eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f5174feab78 in _nss_ldap_enter () at ldap-nss.c:597
#4 0x00007f5176c680c5 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:96
#5 0x00007f517758a249 in fork_exec_with_pipes (intermediate_child=0, working_directory=0x0,
    argv=0x7f516c004830, envp=0x0, close_descriptors=1, search_path=1, stdout_to_null=0,
    stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, child_setup=0, user_data=0x0,
    child_pid=0x7f51717b4a68, standard_input=0x0, standard_output=0x7f51717b4a60,
    standard_error=0x7f51717b4a64, error=0x7f51717b4ba8)
    at /build/buildd/glib2.0-2.32.0/./glib/gspawn.c:1232
#6 0x00007f517758aa44 in g_spawn_sync (working_directory=<optimised out>, argv=<optimised out>,
    envp=<optimised out>, flags=<optimised out>, child_setup=<optimised out>, user_data=0x0,
    standard_output=0x7f51717b4b38, standard_error=0x7f51717b4b40, exit_status=0x7f51717b4b4c,
    error=0x7f51717b4ba8) at /build/buildd/glib2.0-2.32.0/./glib/gspawn.c:285
#7 0x00007f517758b149 in g_spawn_command_line_sync (comman...

Read more...

Revision history for this message
Lennart Karssen (l.c.karssen) wrote :

As metioned in response #36 this problem has returned in Ubuntu 12.04. As reported, the fix in #5 doesn't work anymore.

This is on a machine that was upgraded from 11.10, LDAP client, NFS mounted /home, no Kerberos.

I tried using both my own user account and a freshly created LDAP account with a clean home directory. Both failed. After commenting the lines in /etc/X11/Xsession.d/90qt-a11y gsettings-daemon doesn't hang anymore and many of the 'regular' desktop processes are started (e.g. zeitgeist, deja-dup-monitor, nm-applet) but the screen doesn't show any icons etc. The mouse cursor still works. After switching back from a virtual terminal the screen remains black (with working mouse cursor).

Revision history for this message
Lennart Karssen (l.c.karssen) wrote :

I investigated this some more and found the following:

- Added a local user (not in LDAP, but with home dir on NFS): this user can log in without problems
- For a newly created user in the LDAP server logging in doesn't work and appears to be hanging.
  + Several processes use a lot of CPU time:
    ++ gvfsd-trash --spawner :1.2 /org/gtk/gvfs/exec_spaw/0
    ++ //bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session
    ++ nautilus -n
    ++ compiz
  + related to gvfsd-trash I found that on the NFS server the permissions and time of the directory ~/.gvfs are:
      drwx------ 2 gtest users 4.0K Apr 19 13:53 .gvfs
     whereas on the client machine ls -lad ~/.gvfs gives:
      dr-x------ 2 gtest users K Apr 19 15:36 .gvfs
     (the time on this last entry is correct). Subsequently I killed the gvfsd-trash process a couple of times (until it wasn't restarted anymore) and a partially working desktop showed up. With that I mean: the Unity bar was present, as well as the top menu bar with the status icons. However, in the central desktop space nothing but blackness. No program I started showed a window, although Alt-Tab showed their icons. I could also log out using the menu in the top right corner, but I had to hit the enter key to select logout from the popup window (which I couldn't see).
After that the permissions and time on the .gvfs directory where back at their original state (drwx and 13:53, respectively).

Maybe this bug isn't (only) related to at-spi2-core anymore, but also to gvfs?

Revision history for this message
Lennart Karssen (l.c.karssen) wrote :

After running gvfsd in debug mode from the console (DISPLAY=:0 /usr/lib/gvfsd -r) I found out that gvfsd could not get the right uid for my LDAP users. Googling a bit further I found out that installing the nscd (Name Service Caching Daemon) would solve that problem. And indeed it did!

So, all in all for Ubuntu 12.04 the solution is as follows:
1) Comment the lines in /etc/X11/Xsession.d/90qt-a11y gsettings-daemon
2) Install the nscd package

Revision history for this message
Stephan Fabel (sfabel) wrote :

Running into the same problem with 12.04, LDAP users, NFS Automounted Home Directories. Will try #39; however, what if we need the QT Accessibility?

Revision history for this message
Stephan Fabel (sfabel) wrote :

OK, I am getting past the login screen, no spinning wheel anymore, however it still doesn't work. I've tried #39. The symptom is that after login, the desktop immediately logs me out again and I get back to the login screen.

/var/log/syslog:
May 8 11:32:06 ltsp nbd_server[1494]: connect from 192.168.0.23, assigned file is /opt/ltsp/images/i386.img
May 8 11:32:06 ltsp nbd_server[1494]: Can't open authorization file (null) (Bad address).
May 8 11:32:06 ltsp nbd_server[1494]: Authorized client
May 8 11:32:06 ltsp nbd_server[5105]: Starting to serve
May 8 11:32:06 ltsp nbd_server[5105]: Size of exported file/device is 266027008
May 8 11:32:06 ltsp nbd_server[5105]: Disconnect request received.
May 8 11:32:06 ltsp nbd_server[1494]: Child exited with 0

/var/log/auth.log
May 8 11:32:02 ltsp sshd[4871]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.23 user=sfabel
May 8 11:32:02 ltsp sshd[4871]: Accepted password for sfabel from 192.168.0.23 port 39113 ssh2
May 8 11:32:02 ltsp sshd[4871]: pam_unix(sshd:session): session opened for user sfabel by (uid=0)
May 8 11:32:02 ltsp sshd[5013]: subsystem request for sftp by user sfabel
May 8 11:32:02 ltsp sshd[5013]: Received disconnect from 192.168.0.23: 11: disconnected by user
May 8 11:32:02 ltsp sshd[4871]: pam_unix(sshd:session): session closed for user sfabel

I managed to login if I manually mounted the /home/users directory containing the home directories. So I suppose this error appears to be some interplay issue between autofs-ldap and ldap logins on an LTSP server?

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

High -> Makes a default Ubuntu installation generally unusable for some users ?
(I haven't marked it as triaged because it's not obvious to me from the comment set that anyone really understands where the problem comes from)

Changed in at-spi2-core (Ubuntu):
importance: Undecided → High
Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

Regarding comment #39, where Lennart mentioned to install nscd, I'd like to add that this solved several problems that I have at our company. The setup here is that users login using LDAP account (but we don't use any network FS). Since the upgrade to 12.04, some users started to complain that Thunderbird is always crashing at startup, or that Nautilus doesn't startup. So after installing nscd, those problems went away.

Revision history for this message
airtonix (airtonix-gmail) wrote :

This isn't specific to nfs mounted homes or what have you.

We run a number of 12.04 desktop workstations which I deploy with cobbler, the users authenticate against an ldap server managed by Zentyal, so their home directories are only created on successful authentication.

Revision history for this message
Benjamin A. (benjamin-aupetit) wrote :

#5 and #39 solved the problem under oneiric, but after upgrade to 12.04, the problem reappeared.

Installing nscd and reinstalling at-spi2-core did not solve the problem.

(NFS homedir automounted and LDAP auth)

Revision history for this message
Benjamin A. (benjamin-aupetit) wrote :

After a bit of struggling with the autofs/ldap/nfsd configuration, found out that after restarting
services in order ldap then nfs then autofs, users were able to log-in. And that autofs should be restarted after
the network manager.

Still not sure what caused the problem, but AFAIC problem solved.

(Sorry for the double post)

Revision history for this message
donapieppo (donapieppo) wrote :

Have 12.04, ldap users and no autofs/nfs. Problem solved with #39 installing nscd.

Revision history for this message
ciriffo (piccoccio) wrote :

same problema. ubuntu 12.04, ldap with nfs/autofs. ldap users can log in properly after installing nscd, but only if they use a ubuntu 2D session (or gnome 2D or gnome fallback session).

Revision history for this message
Staten O. (toon0) wrote :

I had the same problem with a fresh install of 12.04 on amd 64 bit. Installing nscd as per comment #39 worked. I DID NOT have to Comment the lines in /etc/X11/Xsession.d/90qt-a11y gsettings-daemon. My users are ldap users with non standard home locations. I did modify /etc/apparmor.d/tunables/ just in case that was causing the problem...Just add /your/user's/home/dir after the line "@{HOMEDIRS}=/home/ . Does anyone know why nscd is not installed by default when libnss-ldap is installed? It is a recommended package, but is not pulled in by default. Anyway, nscd solved my problem and in addition allowed thunderbird to start properly. I know this because I was able to log in once by killing gsettings (see comment #2), during this session, thunderbird would fail on startup with an error of some sort; Not the case after installing nscd. I had this problem with lucid as well. OK, that's it for me...love precise and unity...I think one solution to this issue would be to install nscd by default with libnss-ldap.

Revision history for this message
Jatin Kumar (jatin-iitdelhi) wrote :

Just updated from 10.04 to 12.04. Using LDAP+autofs. Experiencing same problem irrespective of using lightdm or gdm. Tried #5 and #39. Any solution to this problem ?

Revision history for this message
darius (dariuskellermann) wrote :

I've had the same problems on my setup, which is LDAP + NFS via fstab. It works with no changes to the 90qt-a11y, nscd installed and the Ubuntu-2D session. It immediatley fails when logging in with the regular Unity session. For now I adjusted the lightdm.conf to log in to the 2D session by default.

Revision history for this message
ITEAS (info-tux-pc) wrote :

Iv'e installed Edubuntu 12.04 64bit. LDAPusers works fine log into server over Thinclients after installed and starting "nscd". I don't know why i need this service. I have on every system there i need an LDAPconnection an running LDAPslave. This is the best way. Hope nscd do not breaks some things. Strange...

Revision history for this message
Ercash (ercash) wrote :

I have installed Xubuntu 12.04 and configured as LDAP client. I use also automounter for home directories from NFS server. I can login as LDAP user without NFS. Must exist user home directory in NFS? Wenn "no", how i can create?

Revision history for this message
Jameson Perham (jameson-1) wrote :

I can confirm this bug. The fix in post #5 solves it for me but disables QT Accessibility.

Revision history for this message
Tim Carmean (tecarmea) wrote :

I can confirm this bug. Running Kerberos/LDAP/NFS home directories via autofs. I'm running 12.04.1 Desktop on AMD64.

Revision history for this message
Tim Carmean (tecarmea) wrote :

Simply installing unscd seemed to do the trick for me.

Revision history for this message
Luiz Angelo Daros de Luca (luizluca) wrote :

Hello,

I had this problem with 12.04 with nfs home. However, now at 12.10, I also got this with local home.
The BT shows that gsettings stopped at the same point:

(gdb)
#0 __unregister_atfork (dso_handle=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/unregister-atfork.c:117
#1 0x00007f103ac6e823 in __do_global_dtors_aux () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#2 0x00007fffee2ba8f0 in ?? ()
#3 0x00007f103dae691e in _dl_fini () at dl-fini.c:254
Backtrace stopped: frame did not save the PC

I'll try the unscd trick

Revision history for this message
edwinw (edwinw) wrote :

Yesterday, after installing 12.10, I had the same problem in our office environment. Besides the above workarounds, I also read something about a problem of using gvfs on a nfs mount.

Today I started a brand new installation of 12.10, and activated the LDAP client ( apt-get install ldap-auth-client + auth-client-config -t nss -p lac_ldap) and mounted our NFS disk, containing our homedirs. (So, I didn't try #39)

In a terminal I logged in with a LDAP-user and removed ~/.gvfs. I created /tmp/[username]/gvfs and made a symbolic link from ~/.gvfs to /tmp/[username]/gvfs. With lightdm, I logged in as this LDAP-user without any problems.

(I assume that it is not related to this problem, but I also add /etc/modprobe.d/blacklist-floppy.conf containing "blacklist floppy". After a "update-initramfs -u" these annoying "I/O Buffer dev fd0" kernel messages dissapeared)

Revision history for this message
edwinw (edwinw) wrote :

The story continues.....#58 it seemed to work, however after I inserted a DVD in the drive and tried to login with the LDAP-user, the problem occured again. Even logging in with a local (non-LDAP) user shows the same problem.

Remark: after removing the DVD, restarting lightdm and a relogin, I saw the annoying kernel messages again. This time "I/O ..... dev sr0". A gvfs problem? I am not sure what solved the problem in #58. Was it nonetheless the blacklisted floppy module which solved the problem for a short while?

Revision history for this message
PsyMan (1z53) wrote :

I can confirm, 12.04 clean install, followed guide from http://signalboxes.net/howto/linux/ldap-client/
LDAP Server = Snow Leopard
Mounted homefolders using fstab (from Snow Leopard Server via NFS)
Reboot
Symptom:
Login screen seems to accept LDAP Users login and pass but simply returns to login screen after pause.

Solution (temporary and unacceptable for production)
1. If I log in a local user and then log out again my LDAP user can log in OK at the desktop until next reboot.

2. If I log an LDAP user in via terminal (using putty from my PC) all seems to be OK plus, then the desktop login works.

#56 worked on first reboot now reverted back to problem.

About to systematically try others but I thought it worth adding mine to the list.

Revision history for this message
PsyMan (1z53) wrote :

Add on info from #60

It appears that patience is a virtue, I may be simply too eager, it now seems to work after a reboot, I just have to wait for a minute or two before logging on. This is a pain but workable as most of the client machines will be on already.

The plot thickens and thanks for the info.

Revision history for this message
Klaus Steinberger (klaus-steinberger) wrote :

Hi,

install libnss-ldapd and run nslcd and the problem goes aways!
 (maybe sssd will help too)

then nscd works well and no hung problems (even without modifying 90qt-ally script )

Sincerly,
Klaus

Revision history for this message
Matthew Wyneken (mawyn) wrote :

I'm running Ubuntu 12.04, LDAP, autofs and have this problem. I tried #62. It seemed to work at least partially. I was able to complete login some of the time but not all the time. I tried #5 but that didn't seem to make a difference. #14 at http://ubuntuforums.org/showthread.php?t=1526520&page=2 suggests adding "nolock" to the automount / NFS mount options. I tried that and up to now that seems to do the trick.

Revision history for this message
Matthew Wyneken (mawyn) wrote :

Addition to #63: It looks like 90qt-a11y still needs to be deactivated even when using the "nolock" mount option.

Revision history for this message
mKorku (mkorku) wrote :

I'm running Ubuntu 12.04 (fresh install), LDAP and homes mounted via NFS on /etc/fstab.

Installing nscd has solved my problem.

Revision history for this message
Bruno Beaufils (beaufils) wrote :

Same problem here with LDAP users and webdav mounted homedirs on Ubuntu 12.10. No solution presented here has been able to fix anything.

Everything work fine on console.

When deactivating 90qt-a11y the login process end with a message stating that it "Could not update ICEauthority file /home/user/USER/.ICEauthority" which has the good permission (as the homedir).

Revision history for this message
oliver lee (oliver-lee) wrote :

Problem still exists in Ubuntu 12.10

LDAP user authentication and nfs mounted home dirs. (the entire /home directory is exported from the server and is mounted by clients). Partialy fixed by installation of nslcd, did not do #5

Attempting to login immediately after the login screen loads results in the unlocking sound, but takes me instantly back to the login screen. After waiting for a while I can login correctly, same as #61

Interestingly, before I'm taken back to the login screen I get a black screen with the text:
    mountall: disconnected from plymouth
But I'm not sure it's related

Revision history for this message
Mark Abraham (mark-j-abraham) wrote :

Problem observed in fresh install of 12.04. Solved by `apt-get install nscd`

Revision history for this message
Dan Shea (daniel-shea2) wrote :

I can confirm this problem exists on Linux Mint 13 and Ubuntu 12.04
LDAP user authentication with NFS mounted home directories, gsettings process hangs and login will not continue until the process is killed.

Revision history for this message
roberts55 (roberts55) wrote :

Confirming this is a bug as well.
Ubuntu 12.04 with LDAP auth and NFS home directory mounts.

Only seems to affect GNOME Classic and GNOME Classic (No Effects) logins. Hangs after entering credentials.

Changed in at-spi2-core (Ubuntu):
assignee: nobody → Vinoth Rc (vinothrclaksh)
assignee: Vinoth Rc (vinothrclaksh) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.