9.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 username and password or accepts them but then does not behave properly (fails to start the graphic desktop, produces errors, drops to a command line, etc.).

9.4.1.  User Cannot Log In—Valid Username and Password Combinations Fail

This usually occurs when the system 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 a machine might appear functional but be unable to process logins correctly:

  • The network is not working. For further directions on this, turn to Section 9.5, “Network Problems”.

  • DNS is not working at the moment (which prevents GNOME or KDE from working and the system from making validated requests to secure servers). One indication that this is the case is that the machine takes an extremely long time to respond to any action. More information about this topic can be found in Section 9.5, “Network Problems”.

  • If the 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 background information about PAM and the syntax of the configuration files involved, refer to Chapter 16, Authentication with PAM (↑Reference).

In all cases that 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 boot screen appears, offering a prompt.

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

  3. Enter the username and password for root.

  4. Make all the necessary changes.

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

9.4.2.  User Cannot Log In—Particular Valid Username and Password Not Accepted

This is by far the most common problem users encounter, because there are many reasons this can occur. Depending on whether you use local user management and authentication or network authentication, login failures occur for different reasons.

Local user management can fail for the following reasons:

  • The user might have entered the wrong password.

  • The user's home directory containing the desktop configuration files is corrupted or write protected.

  • There might be problems with the X Window System authenticating this particular user, especially if the user's home directory has been used with another Linux distribution prior to installing the current one.

To locate the reason for a local login failure, proceed as follows:

  1. Check whether the user remembered his password correctly before you start debugging the whole authentication mechanism. If the user might not remember his password correctly, use the YaST User Management module to change the user's password.

  2. Log in as root and check /var/log/messages for error messages of the login process and of PAM.

  3. Try to log in from a console (using Ctrl-Alt-F1).

    If this is successful, the blame cannot be put on PAM, 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). For more information, refer to Section 9.4.3, “ Login Successful but GNOME Desktop Fails ” and Section 9.4.4, “ Login Successful but KDE Desktop Fails”.

  4. 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 run rm .Xauthority as this user. This should eliminate X authentication problems for this user. Try a graphical login again.

  5. If graphical login still fails, do a console login with Ctrl-Alt-F1. Try to start an X session on another display, the first one (:0) is already in use:

    startx -- :1

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

  6. If the desktop could not start because of corrupt configuration files, proceed with Section 9.4.3, “ Login Successful but GNOME Desktop Fails ” or Section 9.4.4, “ Login Successful but KDE Desktop Fails”.

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

  • The user might have entered the wrong password.

  • The username exists in the machine's local authentication files and is also provided by a network authentication system, causing conflicts.

  • The home directory exists but is corrupt or unavailable. Perhaps it is write protected or is on a server that 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 that 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 the current one.

To locate the cause of the login failures with network authentication, proceed as follows:

  1. Check whether the user remembered his password correctly before you start debugging the whole authentication mechanism.

  2. Determine the directory server the machine relies on for authentication and make sure that it is up and running and properly communicating with the other machines.

  3. Determine that the user's username and password work on other machines to make sure that his authentication data exists and is properly distributed.

  4. 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, log in and examine the /var/log/messages file. Locate the time stamps that correspond to the login attempts and determine if PAM has produced any error messages.

  5. Try to log in from a console (using Ctrl-Alt-F1).

    If this is successful, the blame cannot be put on PAM or the directory server on which the user's home is hosted, 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). For more information, refer to Section 9.4.3, “ Login Successful but GNOME Desktop Fails ” and Section 9.4.4, “ Login Successful but KDE Desktop Fails”.

  6. 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 run rm .Xauthority as this user. This should eliminate X authentication problems for this user. Try a graphical login again.

  7. If graphical login still fails, do a console login with Ctrl-Alt-F1. Try to start an X session on another display, the first one (:0) is already in use:

    startx -- :1

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

  8. If the desktop could not start because of corrupt configuration files, proceed with Section 9.4.3, “ Login Successful but GNOME Desktop Fails ” or Section 9.4.4, “ Login Successful but KDE Desktop Fails”.

9.4.3.  Login Successful but GNOME Desktop Fails

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, 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 GNOME to initialize a new one. Although the user is forced to reconfigure GNOME, no data is lost.

  1. Log in as root.

  2. cd to the user's home directory.

  3. Move the user's GNOME configuration directories to a temporary location:

    mv ./.gconf ./.gconf-ORIG-RECOVER
    mv ./.gnome2 ./.gnome2-ORIG-RECOVER
  4. Log out.

  5. Have the user log in, but do not allow him to run any applications.

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

    cp -a ./.gconf-ORIG-RECOVER/apps ./.gconf/

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

9.4.4.  Login Successful but KDE Desktop Fails

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

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

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

rm -rf /tmp/kde-user /tmp/socket-user

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

Corrupted desktop configuration files can always be replaced with the initial configuration files. If you want to recover the user's adjustments, carefully copy them back from their temporary location, after the configuration has been restored using the default configuration values.

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

  1. Log in as root.

  2. Enter the user's home directory:

    cd /home/user
  3. Move the KDE configuration directory and the .skel files to a temporary location:

    mv .kde .kde-ORIG-RECOVER 
    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 back into place:

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

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