5.4 Login Problems

Login problems are those where your machine does, in fact, boot to the expected Welcome screen or login prompt, but refuses to accept the proper username/password, or accepts them but then does not behave properly (fails to start the graphical desktop, produces errors, drops to a command line, etc.).

5.4.1 Users cannot log in; the NLD machine refuses to accept any valid username/password combinations.

This usually occurs because NLD is configured to use network authentication or directory services and, for some reason, is unable to retrieve results from its configured servers. The root user, as the only local user, is the only user that can still log in to these machines. The following are some common reasons why an NLD machine might appear functional but be unable to process logins correctly:

  • The network is not working. For help with, see Network Problems.
  • DNS is not working at the moment, which prevents GNOME or KDE from working and NLD from making validated requests to secure servers. One indication that this is the case is that NLD takes an extremely long time to respond to any action, even that of just pressing the Enter key on a blank field in a dialog. This is the DNS lookup timing out for every action that involves addressing the active window in the X Windows system. For more information on this, see Network Problems.
  • If the NLD system is configured to use Kerberos, the system’s local time might have drifted past the accepted variance with the Kerberos server time (this is typically 300 seconds). If NTP (Network Time Protocol) is not working properly or local NTP servers are not working, Kerberos authentication ceases to function because it depends on common clock synchronization across the network.
  • The system's authentication configuration is misconfigured. Check the PAM configuration files involved for any typos or misordering of directives. For additional information on PAM and the syntax of the configuration files involved, see “Chapter 20: PAM Pluggable Authentication Modules” in the SUSE LINUX Enterprise Server 9 Administration Guide.

In all cases which do not involve external network problems, the solution is to reboot the system into a single-user mode and repair the configuration before booting again into operating mode and attempting to log in again.

To boot into single-user mode:

  1. Reboot the system.

    The NLD boot screen appears, offering you a prompt.

  2. Enter 1 at the boot prompt to make the system boot into single-user mode.

    You are prompted for a username and password.

  3. Enter the username and password for root.

  4. Make all the changes you need.

  5. Boot into the full multiuser and network mode by entering telinit 5 at the command line.

5.4.2 A user cannot log in; the NLD machine refuses to accept a particular valid username/password combination.

This is by far the most common problem that NLD machines present, because there are many reasons this can occur. First and foremost, determine that the user’s username and password do, in fact, work on other (properly functioning) machines. If so, then see if another user can log in to the misbehaving machine. If another user can log in without difficulty, or if root can log in, then log in and examine the /var/log/messages file. Locate the timestamps which correspond to the login attempts and determine if PAM has produced any coherent error messages.

The following are some common reasons why authentication for a particular user might fail on a specific machine:

  • The userid exists in the machine’s local authentication files and is in use by a different user.
  • The home directory exists but is either corrupt or unavailable. Perhaps it is write protected or is on a server which is inaccessible at the moment.
  • The user does not have permission to log in to that particular host in the authentication system.
  • The machine has changed hostnames, for whatever reason, and the user does not have permission to log in to that host.
  • The machine cannot reach the authentication server or directory server which contains that user’s information.
  • There might be problems with the X Window system authenticating this particular user, especially if the user's home has been used with another Linux distribution prior to installing NLD.

To locate the cause of the login problems, try the following:

  1. Try to log in via a console (Ctrl+Alt+F1).

    If this is successful, the blame cannot be put on PAM or the directory server the user's home is hosted on, because it is possible to authenticate this user on this machine. Try to locate any problems with the X Window system or the desktop (GNOME or KDE).

  2. If the user's home directory has been used with another Linux distribution, remove the Xauthority file in the user's home. Use a console login via Ctrl+Alt+F1 and issue the rm .Xauthority command as this user, then try a graphical login again.

  3. If graphical login still fails, try a console login via Ctrl+Alt+F1 and try to start an X session on another display (the first one (:0) is already in use) by entering

    startx -- :1

    This should bring up a graphical screen and your desktop as well. If it doesn't, check the log files of the X Window system (/var/log/XFree86.displaynumber.log) or the log file for your desktop applications (.xsession-errors in the user's home directory) for any irregularities.

  4. If the desktop still cannot start up, it is probably due to corrupt configuration files; therefore, refer to A user cannot log in to GNOME Desktop; the NLD machine accepts the username and password but does not bring up the GNOME Desktop properly. or A user cannot log in to KDE Desktop; the NLD machine accepts the username and password but does not bring up the KDE Desktop properly..

5.4.3 A user cannot log in to GNOME Desktop; the NLD machine accepts the username and password but does not bring up the GNOME Desktop properly.

If this is true for a particular user, it is likely that the user’s GNOME configuration files have become corrupted. Some symptoms might include the keyboard failing to work, the screen geometry becoming distorted, or even the screen coming up as a bare gray field. The important distinction is that if another user logs in, the machine works normally. If this is the case, then it is likely that the problem can be fixed relatively quickly by simply moving the user’s GNOME configuration directory to a new location, which causes the GNOME Desktop to initialize a new one. Although the user is forced to reconfigure his GNOME Desktop settings, none of his data is lost.

  1. Log in as root.

  2. Change to the user’s home directory.

  3. Move the user's GNOME config directories to a temporary location by entering

    nld-machine:~user/ # mv ./gconf ./gconf-ORIG-RECOVER nld-machine:~user/ # mv ./gnome2 ./gnome2-ORIG-RECOVER

  4. Log out.

  5. Let the user log in, but do not let them run any applications.

  6. Recover the user's individual application configuration data (including, most importantly, the Evolution™ e-mail client data) by copying the ~/gconf-ORIG-RECOVER/apps/ directory back into their new ~/gconf directory as follows:

    nld-machine:~user/ # cp -a ./gconf-ORIG-RECOVER/apps ./gconf/

    If this causes the login problems to reoccur, it might be time to attempt to recover only the critical application data and force the user to reconfigure the remainder of the applications.

5.4.4 A user cannot log in to KDE Desktop; the NLD machine accepts the username and password but does not bring up the KDE Desktop properly.

There are several reasons why a KDE Desktop might not allow users to log in. Corrupted cache data can cause login problems as well as corrupt KDE Desktop configuration files.

Cache data is used at desktop startup to increase startup performance. If these data are corrupted, startup is slowed down or fails entirely. Removing them forces the desktop startup routines to start from scratch. This takes more time than a normal startup, but the data is intact after this and the user can log in.

To remove the cache files of the KDE Desktop, issue the following command as root:

nld-machine:~ # rm -rf /tmp/kde-user /tmp/socket-user

Replace user with the actual username. Removing these two directories removes just the corrupted cache files, so no real data is harmed.

Corrupted desktop configuration files can always be replaced by the initial configuration files. If you want to recover the user's adjustments, replace them after restoring the configuration.

To replace a corrupted desktop configuration by the initial configuration values, proceed as follows:

  1. Log in as root.

  2. Change to the user's home directory by entering

    nld-machine:~ # cd /home/user

  3. Move the KDE configuration directory and the .skel files to a temporary location by entering

    nld-machine:~user/ # mv .kde .kde-ORIG-RECOVER nld-machine:~user/ # mv .skel .skel-ORIG-RECOVER

  4. Log out.

  5. Let the user log in to this machine.

  6. After the desktop has started successfully, copy the user's own configurations adjustments back into place by entering

    user@nld-machine:~ > cp -a .kde-ORIG-RECOVER/share .kde/share

    HINT:If the user's own adjustments caused the login to fail and continue to do so, repeat the procedure as described above but don't copy the .kde/share directory.