On Thu, Jan 26, 2012 at 9:46 AM, Michael Weiner <hunter at userfriendly.net> wrote: > 5) i tried mounting manually, creating a $home directory for a new > user, giving that user a password and i can ssh in but not Gnome or > KDE If it was me, I'd try creating a new home directory for that user on a disk local to the machine where you're trying to log in. Presumably the user could then log in. Then I'd check that the user could access the NFS share normally just not as home. If no problem there, I'd be a bit tempted to stop there as a workaround, because I am lazy and most of my users just use one machine. Seems possible to me that the dmrc file error message and the instant logout are related but not identical. Gnome just does not like NFS home dirs. (My experience has been, if the same user is logged in to two machines, kablooey!) I used to frequently see a similar problem, after a crash or other odd event, where the user could log in but then would immediately be logged out with an error similar to your second message. I had a magic trick I had to go through to untangle things, if you are desperate enough you could try it: * delete all files in the user's home dir that start with .gconf (.gconf and .gconfd). * delete all files in /tmp. * reboot to make sure all processes release old corrupted files. * if feeling paranoid, before having the user try to log in, check again as root that /tmp is empty and nothing in user's home dir is named .gconf*. One of the symptoms of my problem was, after the user tried to log in and failed, there would be some processes owned by that user alive or in zombie state but still part of ps output, although of course the user was not logged in. These must be killed (or overkilled with reboot) and all traces in /tmp removed. But this would show up in the log of the machine where user is trying to log in (if I recall) as some complaint about gconf. So this may be a goose chase for you, since KDE also fails. I'm not sure what (if anything) they would have in common. Oh well. Dave