Skip to main content
added 580 characters in body
Source Link
slm
  • 380k
  • 127
  • 793
  • 897

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

References

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

Source Link
slm
  • 380k
  • 127
  • 793
  • 897

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

References