Unable to log in user - This gets serious

[Bob Chiodini]

On Wed, 2005-02-23 at 21:39 +0100, Truls Gulbrandsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Tony Dietrich wrote:
> | On Tuesday 22 Feb 2005 20:58, Truls Gulbrandsen wrote:
> |
> |>Alexander Dalloz wrote:
> |>| Am Di, den 22.02.2005 schrieb Truls Gulbrandsen um 21:32:
> |>|>I have upgraded two of my systems, a TP30 and an IBM desktop, with the
> |>|>most resent udates.  After upgrading I am unable to log in as user.  The
> |>|>message I receive is: "GDM could not write to your authorization file.
> |>|>This could mean that you are out of disk space or that your home
> |>|>direcoty could not be opened for writing. In any case, it is not
> |>|>possible to log in. Please contact your system administrator".
> |>|>
> |>|>I am able to log in as root.  I am quite sure that there is enough disk
> |>|>space so the problem is probably something else, but what?  Any
> |>|>suggestions that will assist.
> |>|>
> |>|>
> |>|>Truls
> |>|
> |>| Any chance you changed the permissions or ownership of /tmp by accident?
> |>|
> |>| $ ls -ld /tmp
> |>| drwxrwxrwt  31 root root 1688 22. Feb 20:29 /tmp
> |>|
> |>| This is "chmod 1777" and a must.
> |>| Check too the permissions and ownership of your user's /home/<user>
> |>| directory.
> |>|
> |>| Alexander
> |>
> |>I have only done a "yum update".  The permissions of /tmp is equal to
> |>the above.
> |>
> |>Truls
> |
> |
> | Try removing any sub-directory of /tmp that includes a user's name.
> |
> | Authorisation files are written to files in directories such as
> | mcop-<loginname>, and in some cases updates corrupt the setup of these
> | directories, by either changing the userID of the authorisation
> process, or
> | the method of writing the authorisation file.
> |
> | If that doesn't work, try checking the home directories of each user
> for files
> | under the .kde|.gnome|.whatever_window_manager_you_are_using directory
> for
> | authorisation files.  The rationale for this is the same as above, as
> some
> | authorisation files are stored in the user's directories in some
> cases.  This
> | route may have additional consequences though so YMMV, and the risk is
> yours.
> |
> Hi again,
> now I get worried.  I am still not able to log in with the established
> user ids.  Also, I am unable to create and use new user ids - well i can
> create but get the same errormessage.  The only one working is root.
> Is this a weakness with this distribution or with Linux?  Am I at risk
> (of course I am) that this will happen to pcs with FC3?  Now I don't
> risk doing an upgrade and reboot of this "live" machine.
> 
> Regards,
> Truls

Truls,

This sounds like something is wrong with the permissions on one of the
following /tmp/.ICE-unix, /tmp/.X0-lock, /tmp/.X11-unix.  When I've had
problems logging into X as normal users, I've deleted these files and
directories from /tmp.  ctrl-alt-F1, login as root, init 3, then delete
the above mentioned files and directories, init 5 and try logging in as
a normal (non-root) user to GDM.  

A couple of other thoughts:  The /tmp/.font-unix directory may also
contribute.  Stop xfs before deleting that one.  Lastly, I hope, the
gconfd-<user-name> directories can also safely be deleted in init level
3.

Since it happens to all of your non-root users it's not likely a home
directory problem, unless the permissions or ownership of the home
directories or /home itself are messed up.  /home should be 

        drwxr-xr-x  8 root root 4096 Dec 28 07:30 /home

and as Alexander pointed out /tmp should be:

        drwxrwxrwt  15 root root 4096 Feb 23 19:21 /tmp
        
I would not have thought an upgrade would have corrupted any of these.
More likely a system or X crash.

Bob...