I run Arch Linux with the window manager BSPWM (so no DE) and recently I have been having a problem with my .Xauthority file.

I am no longer able to start my X server because it is unable to write to my .Xauthority file. When I tried deleting my .Xauthority file in hopes of arch creating a new .Xauthority file for me when I logged back in, a new .Xauthority file is not being created.

I've tried recreating the .Xauthority file manually and changing its permissions, but it still has not worked. In addition, I have a .Xauthority-n file in my home directory, I am not sure what this does - but when deleted, it reappears when I log back in.

When the .Xauthority-n and the .Xauthority files are present, on startx it gives me this error:

xauth: unable to write authority file ~/.Xauthority-n

I am not sure why it doesn't try to use the regular .Xauthority file.

How do I get xauth to be able to write to my .Xauthority file? And what is the purpose of the .Xauthority-n file and how can I get rid of it?

  • Have you tried using startx? – Arpit Agarwal Nov 18 '17 at 7:36
  • Yeah, when I run startx it also gives me the same error and then just shows a black screen. – Surya R Nov 18 '17 at 18:01
  • try this xinit /usr/bin/startxfce4 -- /etc/X11/xinit/xserverrc -nolisten tcp vt1 -auth /tmp/user.xinit – Arpit Agarwal Nov 19 '17 at 11:11
  • replace /usr/bin/startxfce4 with your DE path – Arpit Agarwal Nov 19 '17 at 11:12
  • I do not use a DE, I use Arch Linux with the window manager, BSPWM. – Surya R Nov 20 '17 at 5:26

When xauth is updating the .Xauthority file, it will initially write a new version of it as .Xauthority-n. Once the file is completely written, it will move/rename it to .Xauthority, causing the old version of the file to be deleted at the same time.

This relies on the fact that rename/move operations within a single POSIX-compliant filesystem are supposed to be atomic: the operation cannot ever stop half-way, but either it will complete successfully or the old file will be left unchanged.

If the xauth command finds that the .Xauthority-n file is already present, it assumes it means another instance of xauth command is already doing some changes, and refuses to do anything. So this also protects the file from corruption caused by multiple instances of xauth running at the same time as the same user.

The fact that a .Xauthority-n file remains in your home directory suggests that an earlier copy of xauth was terminated in mid-operation before it could execute the rename/move operation for some reason.

You should log out of the X GUI, then login either remotely or using the text-based virtual console, and then delete both .Xauthority and .Xauthority-n. After that, the GUI login should work normally, unless you have some other problem that prevents the system from creating/overwriting the .Xauthority file in your home directory.

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.