LDAP user with automounted nfs homedir cannot login

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.

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

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

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.

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

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?

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.

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

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

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.

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

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.

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)

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

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

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

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.

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

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.

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

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

Has anyone tried an nfs downgrade to a previous version?

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?

Hi,

This bug also affects the 12.04 alpha2 release

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.

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

this should be "grave"

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?

Confirmed #33: it works here too.

It works here too now.

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

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

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?

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

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?

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?

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.

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.

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

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)

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

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

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.

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 ?

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?

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

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

Simply installing unscd seemed to do the trick for me.

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

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)

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?

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.

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.

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

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.

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

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

Installing nscd has solved my problem.

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

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

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

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.

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.