Why am I getting this message from xauth: "timeout in locking authority file /home/<user>/.Xauthority"?

While attempting to SSH into a host I received the following message from xauth:

/usr/bin/xauth: timeout in locking authority file /home/sam/.Xauthority

NOTE: I was trying to remote display an X11 GUI via an SSH connection so I needed xauth to be able to create a $HOME/.Xauthority file successfully, but as that message was indicating, it was clearly not.

Attempts to run any X11 based apps, such as xeyes were greeted with this message:

$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

How can I resolve this issue?

Asked By: slm

||

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

                                              ss#1

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

Answered By: slm

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
Answered By: guettli

SELinux configuration is the very first thing to check out, with …

*/usr/sbin/sestatus*

or

*/usr/sbin/sestatus -v*

If SELinux configuration is set to “Enforcing” it may be causing the “xauth” problem.

 /usr/sbin/setenforce 0

You can set it provisionally to “permisive” mode as follows, (to be able to exclude this issue as a root cause of the problem).

Then follow a SELinux tutorial to put in place a proper configuration, or disable it if you prefer another security method, (f.ex.by editing the /etc/selinux/config configuration file in RHEL v.6)

Answered By: fjcobas

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.

Answered By: searchengine27

For me, two steps:

  1. Created a new user. Logging in as the new user and try X forward using commands like feh.
  2. Log back in as old user and use new user’s ~/.Xauthority file to replace old ~/.Xauthority.
Answered By: Cheng
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.