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

Question

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?

Solution 1

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

Solution 2

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

Solution 3

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.

Solution 4

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)

Solution 5

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.

View more solutions

Comments

[Gilles 'SO- stop being evil']

Do you know what caused those lock files to be left behind?

[slm]

@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.

[MrMas]

You may need to fix SELinux issues before deleting the authority files. See froebe.net/blog/2015/01/20/…

[Ken Sharp]

In my case the file and the directory had the incorrect owner (after copying the user's home directory to another computer).

[Scott - Слава Україні]

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?

[searchengine27]

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]

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.

[0andriy]

In my case the permissions to the /home/user folder were root:root instead of user:user. Fixed by chown user:user /home/user.

[kap]

Confirmed and workaround solves the problem for CentOS 6.9

[Sridhar Sarnobat]

This worked. I need to link to this from all the Ask Ubuntu posts that appear higher in Google search results than this.

[Phlip]

I filled up storage, didn't notice, rebooted, and Xorg wouldn't come back. Nuking the .Xauthority-* lock files fixed it; thanks! (Good thing a civilian didn't get this problem, huh?)