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).

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.

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'.

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?

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.

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.

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".

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.

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 ...)

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.

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.

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.

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.

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

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

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.

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?

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.

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)'

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).

- 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?

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

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.

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?

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)

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.

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.

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.

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.

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.

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...

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?

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)

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?

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.

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.

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

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.