Hello, yesterday I did some testings with user accounts that were not able to log in to LTSP (password is accepted, a black screen shows up for a second, then the login screen comes back; no KDE splash screen or anything).
There are no logs in .xsession-errors, so I logged in via ssh on tjener and tested those users that were not able to log in on ltsp on a terminal: User 1 could log in as soon as I removed his .mozilla directory. I double checked that quota was not the problem. Actually, I just renamed .mozilla to .motzilla; after logging out, I renamed .motzilla back to .mozilla, but this didn't block the account. So this makes me guess that some autostart process (or session restorage) was dropped when .mozilla was missing - and didn't step in any more after restoring .mozilla. For user 2, I checked .kde/Autostart first (nothing!), then removed some session links (cache, tmp) from .kde. No success. I renamed .mozilla/plugins and removed the latest biggest files in .mozilla/firefox. No success. Then I moved .mozilla/mozver.dat (which has global plugin paths) to /tmp - and voila: user 2 was able to login now. Same thing: After logging out and restoring mozver.dat, the account still worked. Searching the web brought me to this Gentoo bug that might be related: http://bugs.gentoo.org/90438 As I understand it, firefox wouldn't start if mozver.dat and others have wrong user IDs due to NFS mount (stale?). What I have to try next time (when I get new blocked account samples): - login from a workstation - change the startscript for firefox according to http://bugs.gentoo.org/90438 Any further hints/comments...? Cheers Ralf -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
