Re: [gdm-list] /tmp and "GDM could not write to the authorization file"

[Brian Cameron <Brian Cameron Sun COM>]

jdege:

There are a few things you should look at:

1) GDM is picky about the ownership and permissions of your $HOME
   directory and sometimes will not create files if the permissions are
   not what GDM thinks are sane.  Note the "RelaxPermissions"
   configuration option.  By default it is 0, which is picky.  Try
   changing the value to 1 or 2 and see if the problem goes away.  If
   so, then you can decide if you like GDM to have more relaxed
   permissions or if you want to fix whatever ownership/perm issue is
   causing your problem.

   If this is your problem, and you want to know what the specific
   ownership/perm issue is, then make sure RelaxPermissions is 0, turn
   on GDM debug, run gdm-restart as root to restart GDM.  Then recreate
   the problem.  You should then find debug messages in your syslog
   (/var/log/messages or /var/adm/messages or /var/log/syslog or
   similar depending on your system).  The debug messages should mention
   the specific failure.  So if it says your $HOME ownership or
   permission is invalid, you should easily be able to correct this.

   Even if RelaxPermissions isn't the problem, checking the debug log
   should be helpful in figuring out what the problem is.  If you
   can't figure out the problem, share with us the gdm-related debug
   messages from your syslog.

2) You might be bumping into this bug:

   http://bugzilla.gnome.org/show_bug.cgi?id=171188

Let us know if this helps.

Brian



> I'm running CentOS 5, with whichever version of GDM is current in that
> distribution.
>
> I've been trying to work out a reliable backup method, and I ran into an odd
> problem.
>
> I was using LVM snapshots, to get clean partition images, and using tar and
> gzip, onto a removable HD.
>
> After I untar'ed onto a clean disk, I'd get the message "GDM could not write
> to the authorization file" when I tried to log in as an ordinary user. 
> Console logins for ordinary users worked fine, and GDM logins for root
> worked.  But ordinary user logins through GDM did not.
>
> Google revealed that the cause of this was often a lack of disk space.  In
> my case, none of the partitions had less than 40% free space.  A second
> possibility was permissions or ownership.  I was pretty certain that running
> tar with --preserve --xattrs would keep the permissions and ownership
> correct.
>
> But I still couldn't log in.  So I replaced tar with dump and restore. 
> After a full level 0 backup - from read-only snapshots - and a full level 0
> restore onto a newly formatted drive, when I booted off that new drive, I
> got the same problem: "GDM could not write to the authorization file"
>
> I had been keeping /tmp on a separate partition, and I'd not been including
> it in my backups or restores.  But in an act of pure desperation, I added
> /tmp to the backup.  And after the restore, I could log in fine.
>
> So, my question.  What files or directories in /tmp is GDM relying upon,
> when logging in an ordinary user?
>
> And why, exactly, is it not reconstructing them, if they aren't present?  I
> haven't got a problem with a program putting files into /tmp.  But if it's
> depending upon their continuing to be there, from one boot to another, it's
> broken.
>
> I should not have to backup /tmp, to be able to restore a working system.  I
> should be able to delete everything in /tmp, periodically, and still have a
> working system.
>
> The whole purpose of /tmp is to have a known place to keep transient files,
> so that they don't get backed up, and so that they can be cleaned up on a
> regular schedule.
>
> Am I the only person to have run into this?