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. Sep 3, 2014 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, 2014 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, 2014 at 13:19

10 Answers 10


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 there are no more problems with .Xauthority file since then.

Thanks and credits to srinivasan.

  • 2
    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, 2017 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. Oct 22, 2017 at 17:36
  • 46
    step 3 gives me the error: xauth: (argv):1: unable to open display ":0".
    – simpleuser
    Jul 12, 2018 at 5:33
  • 1
    @simpleuser replacing :0 with $DISPLAY worked for me as I use XQUARTZ as an X11 server on my mac laptop
    – Ajay
    Jan 6, 2021 at 18:23
  • 1
    @Amir, as a gitlab-server is just a webapp, does no seems to make any sense Xorg to cause it to be down, I do suggest to you check how the service is setup. But in gitlab-runners it can be a problem depending on what kind of projects dependencies you are building. Probably specific to a project repo CI build. You need to check for example if the project is recreating the xauth setup inside a new container that is not so simple to integrate with host Xorg because the libs can be in different versions. Anyway it's very hard to tip without know more about your context.
    – ton
    Jul 9, 2021 at 13:11

Under root privileges open /etc/ssh/sshd_config and uncomment the following lines if they are commented:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Then logout and login again with -X flag in ssh. You do not have to set or unset DISPLAY environment variable.


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


Found another potential cause of xauth not creating the .Xauthority file by following a couple of the answers above. Should become immediately obvious if you are following Ton's answer:

$ touch ~/.Xauthority
touch: cannot touch ‘/nethome/jdoe/.Xauthority’: Disk quota exceeded

The above will happen if you exceed the "number of files" quota for your user. If you exceed the space quota, you will likely see that error message at a different step. Or, to test if its a space disk quota issue, type:

echo "hello, world" > ~/hello.txt

If the echo gives you a Disk quota exceeded message, then you know that you are using too much space in your home directory (as opposed to too many files or inodes).

Solution in either case? Clean up your home directory!


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.


Here goes another answer, which I would have liked to find (handling the case of forwarding from a VM host to its VM guest):

There may be certain VM images (in my case a KVM image for Ubuntu 18.04) in which for some reason, the default in /etc/ssh/sshd_config for AddressFamily is set to any (I stumbled across this as a possibility here on Redhat's Bugzilla platform after googling an error from running journalctl -xe, with substring "Failed to allocate internet-domain X11 display socket.").

The assumption of course being, that xauth is installed/running.

So, what can be found in the other answers here was not sufficient for me, I needed the settings:

AddressFamily inet
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

The 10 should depend on your host machine's configuration, I had to use X11UseLocalhost no, because otherwise the KVM guest would try to forward to its own displays, not the host machine's displays.

If you are using ssh-agent, then there is

AllowAgentForwarding yes

as well, which probably should be activated.


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.


Another possible reason:

no space left on device (df shows 0 bytes)

Possible fix: e.g. removing python-pip cache.

  • 2
    What question are you answering?
    – Toto
    Nov 29, 2022 at 10:41
  • This is true, no space left on device can be a reason of .Xauthority file issues.
    – ton
    Sep 17 at 14:44

I fixed this issue:

I opened an ssh connection to my server with the -X command option like this

ssh -X user@ip

then I got the Xauthority error. So I just ran this command on the ssh server

touch .Xauthority

Just run this

After that just

nano /etc/ssh/sshd_config

Uncomment the following and replace <username> with your username

Match User <Username>
    X11Forwarding yes
#    AllowTcpForwarding yes
#    PermitTTY yes
#    ForceCommand cvs server

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .