Using CentOS 5:

I backed up my working drive, using 'tar --preserve --xattrs'

Actually, I backed up LVM snapshots of the partitions on my working drive, except for the /boot partition, which I remounted ro for the duration of the backup, so the file images should be clean.

I restored them to a new drive, using 'tar --preserve --xattrs'.

I booted from CD, and ran Grub to configure the new drive to boot, and booted.

GDM comes up fine, but when I try to log in as an ordinary user, I get the error: "GDM could not write to the authorization file".

Googling around shows this is most commonly the result of full partitions. In my case, it's not. A check of 'df -k' shows no partition with more than 50% used.

The only other possibility I can think of are permissions. I boot as root, and look around the file system, and they all _look_ ok. But clearly something is not right.

The immediate question is what? What files or directories should I be looking at, and what permissions should they have?

The more important question, if it turns out that the problem really is a matter of permissions, is why did tar, run with --preserve and --xattrs, not preserve them. And what can I do to make it do so?

===
Addl info - on thinking about it for a bit, I realized I hadn't set the root user's umask, prior to running the untar.

I reformatted the target partitions, and reextracted the tar files, with umask set to 0, and had the same results.
===
Another update - I replaced the backup utility with dump/restore, instead of tar, and I'm still getting the same results.

At this point, I'm at a loss. Restore should restore files without any possibility of modification - no chance of messing up permissions, ownership, or ACLs. But I still get the "unable to write" error.

The only thing I can think of to try now is to add /tmp to my backup set, in the off chance that somebody was stupid enough to write a dependency into a file there.
===
Final update: I added /tmp to my backup set, and now the process is working. There is something, in the GDM authentication process, that is relying upon a file or directory in /tmp being there - which is, in my mind, a fundamentally flawed dependency.

Sounds like you're right; I wouldn't like anything to depend on anything in /tmp either..

Good you got it solved. I would have suggested to check the user/group ID numbers in the new system, in case the backups' permissions were for the right users/groups (in alphabets) but the new system had different ID numbers for the same names. Luckily it wasn't that..

I don't think there's anything wrong with depending upon files in /tmp, I just think there's something wrong in depending upon their not disappearing. If they're not there, GDM should be able to reconstruct them, rather than fail.

OK - I figured it out.

GDM wasn't depending upon anything that was in /tmp, it was depending upon the ability to write to /tmp.

And my restore process, when I didn't restore /tmp, left it with perms of 755 (mkdir with a umask of 022). And GDM would not be able to write a cookie file to it.

When I did restore /tmp, restore would set the perms to 1777, and GDM would be able to write a cookie file to it.

Lesson learned, when doing a restore with dump/restore, make sure to set the perms on all of the mounted partitions you aren't restoring, because restoring / won't set them to what they had been.