I had a user come to me saying they couldn't forward X11 from their home institution to us. I watched them logged in and noticed that xauth was complaining it couldn't lock files. I looked a little deeper and it was that xauth creates a temporary file, then hardlinks to .Xauthority. The problem is that this remote system uses CIFS for home directories (weird huh?). I did some looking and found that ssh has a mechanism to take care of this. The man page has an example script that almost worked for me. I changed it a small amount
XAUTHORITY=/tmp/Xauth-$USER export XAUTHORITY alias xauth=$HOME/xauth if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes echo add `hostname`/unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalHost=no echo add $DISPLAY $proto $cookie fi fi | tee /tmp/ssh.log | xauth -q -
To get this to work properly I made two more changes, I added a script to their home directory called xauth, which just makes sure XAUTHORITY was set and then runs xauth.
#!/bin/sh XAUTHORITY=/tmp/Xauth-mguest20 export XAUTHORITY exec /usr/bin/xauth $@
To add insult to injury, during the testing of this I had a brain fart and was trying to use $0 instead of $@, lame
user@host: ./xauth add MIT-MAGIC-COOKIE etc /usr/bin/xauth: (argv):1: unknown command "./xauth"
:-[

Ok, after that just make sure XAUTHORITY is set properly by the shell (if it is, then the script isn't needed, but just in case...) The user had tcsh (dunno why, religious war I guess, I can't stand csh)

.tcshrc setenv XAUTHORITY /tmp/Xauth-$USER alias xauth $HOME/xauth
After that logout, login again and X should start working.

About the Author...