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. -- Tony Dietrich ------------- Just remember: when you go to court, you are trusting your fate to twelve people that weren't smart enough to get out of jury duty!
