Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

OpenSuSE 10 Quick Start Guide
Previous Page Home Next Page

13.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.).

13.4.1 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 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. Find more information about this topic in 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 typographical errors or misordering of directives. For additional background information about PAM and the syntax of the configuration files involved, refer to Section 18.0, Authentication with PAM, (↑ Reference ).

In all cases that do not involve external network problems, the solution is to reboot the system into 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.

13.4.2 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 13.4.3, Login Successful but GNOME Desktop Fails and Section 13.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 Login Successful but GNOME Desktop Fails or 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 13.4.3, Login Successful but GNOME Desktop Fails and Section 13.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 Login Successful but GNOME Desktop Fails or Login Successful but KDE Desktop Fails.

13.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. Switch to a text console by pressing Ctrl+Alt+F1.

  2. Log in with your user name.

  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. Log in again, but do not run any applications.

  6. Recover your 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 reconfigure the remainder of the applications.

13.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. Switch to a text console by pressing Ctrl+Alt+F1.

  2. Log in with your user name.

  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. Log in again.

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

    cp -a .kde-ORIG-RECOVER/share .kde/share

    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.

OpenSuSE 10 Quick Start Guide
Previous Page Home Next Page

 
 
  Published under the terms fo the GNU General Public License Design by Interspire