Xauth error in locking authority file

I have another answer to the question that plagued me before I figure out the issue. The issue is a bug in Fedora OS and it’s derivatives, as I later figured out. If the issue isn’t as indicated by the accepted answer, and/or you’re not on Fedora, RedHat, Korora, etc, then this won’t help you.

The Problem

As user slm said, running strace will give you an indication of the issue, but in this particular bug’s case, the output is different:

$ strace xauth list
  ...
  stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
  ...

To be clear, this is stating that EACCES return code, which is permission denied. This is different than user slm’s problem, where he had the EEXIST return code, which means File exists. So, for the EACCES return code, obviously the first thing you check is: are my home permissions set up so I am able to write to my home directory? You should verify you have the write flag on your home directory for your own user first. If you do, then you might be a victim of the bug described below.

The Bug

Through a couple google searches I was finally able to find somebody with a similar problem, and it led me to Fedora bug report. For those of you that care to read about it: https://bugzilla.redhat.com/show_bug.cgi?id=772992

The Workaround

The workaround to the issue:

#verify you're not crazy
$ xauth list
  /usr/bin/xauth:  timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority 
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit

When you SSH back in, it should be fine at this point and you should be able to successfully transfer your X-session again.

EDIT (and other alternative workarounds):

Just to be as complete as possible, other users did state in the bug report that the fix above did not work for them — it happened to work for me. Another attempt to work around the problem was (I did not verify this workaround personally):

# setsebool -P use_nfs_home_dirs 1

Another person mentions something about GDM, which I have zero knowledge of. If that pertains to you I recommend reading his post in BugZilla and seeing if his comment means anything to you.

When logging in with ssh -Y remotehost I get the following error message:

/usr/bin/xauth: /home/hlovdal/.Xauthority not writable, changes will
be ignored

And xclock and similar fails to start. There is nothing wrong with the permissions
of the .Xauthority file despite the error message.

(hlovdal) remotehost:~>xclock
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0
(hlovdal) remotehost:~>ls -l /home/hlovdal/.Xauthority
-rw-------. 1 hlovdal hlovdal 70 Jul 25 23:30 /home/hlovdal/.Xauthority
(hlovdal) remotehost:~>

What might be the cause here?

(This is between my two laptops where I have shh-ed back and forth hundreds of times before.)

Update:

While debugging further, xauth again complained that it could not write to .Xauthority
This does not make sense since the file is writable by my user,
and out of curiously I ran strace to see exactly what it tried to do.

(hlovdal) remotehost:~>xauth list
xauth:  /home/hlovdal/.Xauthority not writable, changes will be ignored
(hlovdal) remotehost:~>strace -oout -f -s9000 xauth list
xauth:  error in locking authority file /home/hlovdal/.Xauthority
(hlovdal) remotehost:~>tail out
16634 brk(0xf03000)                     = 0xf03000
16634 brk(0)                            = 0xf03000
16634 rt_sigaction(SIGINT, {0x4050d0, [INT], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGTERM, {0x4050d0, [TERM], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGHUP, {0x4050d0, [HUP], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 rt_sigaction(SIGPIPE, {0x4050d0, [PIPE], SA_RESTORER|SA_RESTART, 0x3957035350}, {SIG_DFL, [], 0}, 8) = 0
16634 stat("/home/hlovdal/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
16634 open("/home/hlovdal/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
16634 write(2, "xauth:  error in locking authority file /home/hlovdal/.Xauthorityn", 66) = 66
16634 exit_group(1)                     = ?
(hlovdal) remotehost:~>ls -l .Xauthority*
-rw-------. 1 hlovdal hlovdal 70 Jul 25 23:30 .Xauthority
-rw-------. 2 hlovdal hlovdal  0 Jul 26 01:26 .Xauthority-c
-rw-------. 2 hlovdal hlovdal  0 Jul 26 01:26 .Xauthority-l
(hlovdal) remotehost:~>

This explains better why xauth fails since it fails to create .Xauthority-c.
But removing those two probably stale files does not help, they are recreated on the next ssh login.
syslog in remotehost contains the following related to the ssh login.

sshd[17551]: Accepted publickey for hlovdal from x.x.x.x port 36545 ssh2
sshd[17552]: fatal: mm_request_receive: read: Connection reset by peer
sshd[17551]: pam_unix(sshd:session): session opened for user hlovdal by (uid=0)

This mm_request_receive error message have never occured before, so I guess there is the clue for further debugging.