I have setup a OpenSUSE 12.3 workstation with SSO through KRB5 and LDAP.

This works pretty smoothly up to the point where GDM isn't very happy about that fact that it cannot access user's home directories that are actually nfs mounts with krb5p.

If no home directory is mounted GDM works fine. If at least one home directory is mounted then GDM will crash when attempting to open the greeter / login screen.

If I remove LDAP (sss) from /etc/nsswitch.conf then GDM will work fine even if the home directories are mounted.

At first I used to have the nfs mount in fstab for /home/users. There GDM would crash every time. Then I have tried to switch to autofs to mount /home/users/* individually. There GDM would work at first but crash thereafter (when the user logs out). Now I have configured it to use pam_mount so that the home directories would get unmounted after a user logs out. Now GDM works as long as there is no other user logged on to the system.

So the problem must be somehow related to the fact that if the user gdm that the GDM greeter uses tries to access any of the mounted home directories, its permission will be denied by the nfs server due to a missing kerberos ticket. Even root cannot access these directories.

Any attempt to give GDM access to these directories before the respective user logs in, would be a security issue.

Interestingly though if the home directory doesn't exist then GDM has absolutely no problem with it. So GDM does tolerate file does not exist, but doesn't tolerate permission denied.

So this makes me conclude that whatever GDM is trying to access from the home directories is not required at all.

So what is it that GDM is trying to get from the home directories? And more importantly, how can I disable it from trying to do so? How can I prevent it from hanging? Any ideas for some extra troubleshooting?

Or how can I make the mounted home directories invisible to GDM so that it won't trip over them?

3 Answers 3


Issue with /etc/gdm/*

In looking at the GNOME Display Manager Reference Manual I noticed several directories under /etc/gdm with different scripts and such.

There are a couple of references in these directories to $HOME. I'd try commenting those out to see if you can get rid of the access to $HOME.

To debug your issue further I'd be inclined to throw a couple of set -x lines at the top of the various scripts in these directories to see what's running prior to the "permissions denied" messages.

The script in the directories are all bash scripts on my systems.


debug option

There is a debug option in this file that is disabled by default. Try enabling it, the messages will show up in /var/log/messages.


Disable faces in login

I'd also try disabling the inclusion of all user's faces at the gdm login in the face browser.


Instead of disabling it you could experiment with disabling just one of your problem users by adding them to this list:

Exclude=<some user>

Update #1 - bugzilla issue

The issue appears to be related to this bug filed against the Red Hat Issue tracker, titled:

There is no resolution but as part of the bug there was a test to confirm that you were experiencing this bug.

When the problem shows up GDM apparently creates a cache directory here: /var/run/user/42. Deleting this directory allows GDM login to proceed. The OP has confirmed this in the comments.

Update #2 - possible workarounds

There was a 2nd comment (by me) to some additional links with suggestions to work through the issue. The link titled:

specifically in this section:

had some modifications to the PAM setup that might fix the issue.

  • It is weird, but I cannot exclude any of the users faces with Exclude although the debug and IncludeAll flags do work, but do not solve the problem. Debug doesn't show any related error messages. I don't see the point in removing references of $HOME as $HOME will only refer to the inaccessible user directories after the respective users have already logged in. GDM hangs before the users even get a chance to log in. May 26, 2013 at 3:43
  • Any luck with setting set -x at the top of the scripts in /etc/gdm?
    – slm
    May 26, 2013 at 3:45
  • Also what is the server you're going against for your SSO? Linux or Windows?
    – slm
    May 26, 2013 at 3:51
  • the server is Ubuntu 12.04 May 26, 2013 at 4:17
  • I have looking at how to capture the output of set -x. It seems to be none of these scripts are executed before GDM starts hanging. May 26, 2013 at 16:07

One thing that gdm might look in home directories for is to get users' photos for displaying in the user list.

I think OpenSUSE uses gdm 3.6.2, is that correct?

Two things I suggest doing:

  1. Enable debug logging as per gdm debugsection, try re-running gdm, and then see if there's anything useful in your system logs
  2. Try disabling the user list as per Simple Greeter Configuration
  • I've tried 1., but didn't get any related error messages. I've also tried 2., and it seemed like SUSE doesn't really support that. Will try again though. Yes, it's 3.6.2. May 21, 2013 at 5:40
  • Ok the Simple greeter configuration is totally ignored on OpenSUSE. Also, I think that if peterph is right about .dmrc, then disabling the user list will only delay the hang until user attempts to log in as it then would attempt to read the window-manager preference. May 22, 2013 at 10:22

It might be looking for .dmrc or something similar to load user session settings from. To make sure, attach to the gdm process with strace and check what files it is trying to open (and where it hangs). You probably want to use something like:

strace -f -o /path/to/logfile PID_OF_GDM

-f traces children processes as well, -o redirects log to a file (instaed of stderr).

If this is the case, putting the file into the user directory before it is mounted should fix the issue (but user won't be able to change it).

If it's not easily possible to attach to GDM before it crashes, you can edit the launcher (either the appropriate systemd unit or - if you are still sticking with sysvinit - the init script).

However, the safest way to catch it is to replace gdm with a wrapper script that would call the original binary (renamed to e.g. gdm.bin). Then no matter how the manager is spawned, it is going to be traced. You might also want to use a uniquely named file for output - just use $$ and/or `date --iso=ns` in the wrapper script:

strace -f -o /path/to/gdm-${$}-$(date --iso-8601=ns).strace \
  • I don't think your solution will work as once the home directory is mounted GDM will not be able to access the .dmrc anyway, unless we can rely on it being cashed. But then SUSE restarts GDM when somebody logs out. I will check the strace method to see what is really going on, but there again the PID keeps changing as GDM is being restarted. May 21, 2013 at 5:38
  • First of all, trace the gdm process so that you know what's going on. As for accessing the file: once it is open, it stays available for the process that has opened it even when something else is mounted on an ancestor directory - that's how file systems work on Linux (and unix in general afaik). Of course it's preferred to have the same file in the regular $HOME as well (and to synchronize those).
    – peterph
    May 21, 2013 at 8:54
  • I have real trouble getting anything meaning full out of strace. The PID keeps changing, because at logout X11 restarts. For the same reason GDM would also need to reopen the .dmrc files. I've tried it and it doesn't solve anything. May 22, 2013 at 10:24
  • Just put the strace log somewhere so that somebody can look at it - obviously the best way would be to watch it with e.g. tail -f while the action happens so that you can see any possible freezes. What happens when you first log in on console and get a Kerberos ticket? Does that solve the problem?
    – peterph
    May 22, 2013 at 10:54
  • That's the problem. GDM freezes very soon after it starts. If I mount the directory after it has already started, then it won't freeze. So getting the trace is very tricky. Getting the kerberos ticket first wouldn't help as GDM doesn't seem to be using a kerberized user to access the directory. It is either accessing it as root or gdm I think. May 22, 2013 at 11:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .