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?

up vote 27 down vote accepted

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

  • 1
    Do you know what caused those lock files to be left behind? – Gilles Jul 13 '15 at 22:45
  • @Gilles - no I had the same thought. I deleted them and then thought, I should've tried to delve into what was controlling them using lsof. I'd seen them before but cannot remember where. I thought you and I discussed them at one point prior but couldn't find any mention of them on the site. – slm Jul 14 '15 at 0:04
  • 1
    You may need to fix SELinux issues before deleting the authority files. See froebe.net/blog/2015/01/20/… – MrMas Nov 1 '16 at 17:45
  • In my case the file and the directory had the incorrect owner (after copying the user's home directory to another computer). – Ken Sharp Apr 3 '17 at 1:18

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.

  • 1
    For all its length, this is unclear. What is the problem? What is the solution / workaround? What does it do? When should we expect solution #1 not to work? – Scott Sep 26 '17 at 1:34
  • I don't understand what you're asking. The question had a pretty clear problem. The solution 1 had a pretty clear solution to a variation of that problem. Solution 1 had a pretty clear way of indicating what the problem specifically was in his answer. My problem was clearly different, as indicated above, which is why my solution to resolving that problem was also clearly different. What do you need clarification on that would make this more obvious I guess is my question to you? – searchengine27 Sep 26 '17 at 15:03
  • I tried to make some updates to the answer, but I honestly don't know how to make it more clear than that without knowing what specifically troubles you about it. – searchengine27 Sep 26 '17 at 15:12

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)

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.