Why am I getting this message from xauth: "timeout in locking authority file /home/<user>/.Xauthority"?
Running an strace on the remote system where xauth is failing will show you what's tripping up xauth.
For example
$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
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}, 0x7fff6c4430e0) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
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}, 0x7fff6c4430e0) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
So xauth is attempting to open a file and it already exists. The culprit file is /home/sam/.Xauthority-c. We can confirm the presence of this file on the remote system:
$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam 0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam 0 Jul 12 22:36 .Xauthority-l
The fix
As it turns out. Those files are lock files for .Xauthority, so simply removing them resolves the issue.
$ rm -fr .Xauthority-*
With the files deleted, exit from the SSH connection and then reconnect. This will allow xauth to re-run successfully.
$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$
Now we're able to run xauth list and X11 applications without issue.
$ xauth list
blackbird/unix:10 MIT-MAGIC-COOKIE-1 cf01f793d2a5ece0ea58196ab5a7977a
The GUI
$ xeyes
Alternative method to resolve the issue
I came across this post titled: xauth: error in locking authority file .Xauthority [linux, ssh, X11] which mentions the use of xauth -b to break any lock files that may be hanging around. xauth's man page seems to back this up:
-b This option indicates that xauth should attempt to break any
authority file locks before proceeding. Use this option only to
clean up stale locks.
References
- Dealing with xauth “error in locking authority file” errors
The root of the problem could be that you have no write permission in the $HOME directory.
That's why I got this message:
/usr/bin/xauth: timeout in locking authority file /home/fooftp/.Xauthority
Here is how I checked the permission:
fooftp@for-fun-work:~> ls -l .Xauthority
-rw-r--r-- 1 fooftp fooftp 1 Sep 14 2015 .Xauthority
# Conlusion: I can write this file: ok
fooftp@for-fun-work:~> rm .Xauthority
rm: cannot remove '.Xauthority': Permission denied
# Conlusion: strange ... I can't delete it
fooftp@for-fun-work:~> id
uid=1001(fooftp) gid=1000(fooftp) groups=1000(fooftp)
# Conlusion: Yes, I am user fooftp
fooftp@for-fun-work:~> ls -ld .
dr-xr-xr-x 14 fooftp fooftp 4096 Sep 14 2015 .
# Conlusion: Bug found :-)
# The permissions should be "rwx" for you.
If this is the problem, then you need to be sure that you have write permissions to $HOME:
chmod u+rwX $HOME
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.