When I ssh into a headless Linux Mint 17 system, it doesn't create update / create an .Xauthority file.

Moreover, when I run xauth I get the reply:

marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority

It doesn't create the file.


When I connect monitor, then log in locally, the file is created but when I try to add an entry (because my SSH doesn't do it for me):

marty@N40L ~ $ xauth list
N40L/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep  3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1:  unable to open display "localhost:10.0".

Incidentally, doing a netstat --listen shows the port listening:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, more info. I logged out of the X session on the server, and now the .Xauthority file has disappeared. It seems the file is ONLY there when logged in locally. Can anyone tell me why, or how I can fix this?


I created a virgin user on the system called "test". I then logged in, and without ANY other commands, ran xeyes. Which worked! So it's ONLY the user "marty" that cannot xforward. How do I copy the settings from test to marty?

  • Did you tell it to create the file? ssh -X enables X11 forwarding. – grawity Sep 3 '14 at 10:47
  • Yes, I'm using Putty on Windows, setup for forwarding (works on connecting to another Mint server). But the file is not created, so I thought I'd add it manually, xauth doesn't create it manually either. – wkdmarty Sep 3 '14 at 10:49
  • Local Xwindows creates the .Xauthority file, but Putty SSH session doesn't. Even though it shows it listening for the connection. – wkdmarty Sep 3 '14 at 13:19

Just to report, I did have a similar problem. But in my case i just follow those steps:

Follow these steps to create a $HOME/.Xauthority file.

Log in as user and confirm that you are in the user's home directory.

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list 

After that no more problems with .Xautority file since then.

Thanks and credits to srinivasan.

  • 1
    in my case, I had an environment variable XAUTHORITY pointing to somewhere else (a careless mistake), using this [prefetch.net/blog/index.php/2011/11/01/… thread I was able to discover this and resolve the error. Using strace xauth, it pointed out the incorrect path specified in the variable. I should also add that I was getting locking errors aswel, amongst others – Cybex May 23 '17 at 23:32
  • 1
    In my case, I only had to do step 1 to 3. Step 4 and 5 actually made it not work. – Richard Ayotte Oct 22 '17 at 17:36
  • I have to do xauth generate :0 . trusted after every command as user to open a display as root. Can I make it fix? – Timo Mar 12 '18 at 19:43
  • xhost + helped to open x-apps as root. – Timo Mar 12 '18 at 20:38
  • 4
    step 3 gives me the error: xauth: (argv):1: unable to open display ":0". – simpleuser Jul 12 '18 at 5:33

Just to complement the excellent ton's answer.

I have once had exactly the same problem because my home directory had become 100% full. Upon connection, ssh created an empty ~/.Xauthority and was unable to write any single entry to it (so that xauth list had always produced an empty output).

So I suggest one always checks the free space (e. g.: df -h) and verifies that xauth generate and xauth add have indeed had any effect (xauth list).


After finding out that it wasn't the system, by adding a test user (which x forwarding worked "out the box"), I thought I'd start copying the .bash* startup files across to virginise the "broken" user.

None of the files were different, so next I deleted the users .ssh directory. When I ssh'd in, it moaned about "Server refused our key", but I could log in using password. Once logged in, I could x forward perfectly.

I'll now try to setup the key again and see if I can get that working too. Then it'll be back to normal.


Moving the .ssh directory out of the way made X forwarding work for me.

Through process of elimination, I found a file in ~/.ssh that was called "rc", and contained:

echo "Wecome to $(hostname), $(whoami)"

I never created this, and have no idea where it came from. Removing it fixed the issue, and my authorized_keys, known_hosts, and key files can all stay intact.


I came across this same issue on two servers that were technically sister nodes. Pain in my tail, as I couldn't figure out what was different. Turns out the /home directory was full, so .Xauthority files couldn't populate properly. Once I located the file(s) taking up too much space and purged them, new .Xauthority files were created properly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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