11

Somehow, while playing around with LightDM and Webkit Greeter, the ownership of the .Xauthority file in my home dir was given to the root user and I couldn't login because I hadn't the privilegues to lock the file.

I was able to regain ownership of the file and I could login again. (After several hours of reinstalling LightDM and it's greeters)

So now everything's working fine again. But I'd like to know how this happened. Is this a bug in LightDM or Webkit Greeter or something else?

2 Answers 2

11

Almost certainly not, no. You either started an X session as root (not sure how you managed that) or simply used touch or otherwise wrote .Xauthority with sudo. For more details, you'd have to explain what you were actually doing.

Next time, don't reinstall anything, just delete the ~/.Xauthority file, it will be recreated automatically next time you log in:

sudo rm ~/.Xauthority

Then log in normally.

5
  • To find where the problem was I once ran sudo startx, what worked. After changing the ownership of the file I could login again. So did starting X as root just fix the original problem?
    – s3lph
    Mar 20, 2014 at 14:58
  • @the_Seppi no, running sudo startx started an X session which was owned by root who was the owner of .Xsession and so could log in. You then changed the ownership which allowed your user to log in again. Next time, just delete the file, as I said, it is recreated automatically on login, no point in "fixing" its permissions.
    – terdon
    Mar 20, 2014 at 15:02
  • But it fixed it. And I didn't do anything else to .Xauthority. Btw. what's the purpose of this file?
    – s3lph
    Mar 20, 2014 at 15:03
  • 1
    @the_Seppi yes, it fixed it. The .Xauthority file is basically a magic number used to identify the owner of an X session so that other people can't hijack it. If you are running an X session and I am logged in to the same machine, I won't be able to access your X session unless I am the owner of the .Xauthority file. It is created whenever you log in unless one exists. So yes, changing the permissions to your user will fix it but so will simply deleting it.
    – terdon
    Mar 20, 2014 at 15:08
  • I had this same issue; it got that way by me trying to run startx as root after trying to recover from a botched update that disabled bluetooth. I've been trying for hours to get the GUI back. It turns out to be Super Simple! Delete all the .Xauthority lock files, delete the .Xauthority file, and restart. <rant>It's little secrets like this, that are so hard to find if you're not in the know (or it's been too long since you were), that currently make linux a poor choice for many people who could otherwise use it.</rant>
    – hlongmore
    Dec 5, 2018 at 13:59
3

It happened to me too. I think that it could be caused by running

sudo graphic_application

instead of

gksudo graphic_application 

for some (unknown) app. There is a paragraph in the sudo help page about that... scroll down to "Graphical sudo".

See also What is the difference between "gksudo nautilus" and "sudo nautilus"?

2
  • That should't affect the .Xauthority, that is created when the X session is started, it won't be touched by subsequent launches of GUI apps.
    – terdon
    Mar 20, 2014 at 15:52
  • @terdon you're right --- unless you use startx or similar. I was playing with Xnest when I was bite by it, probably operator error.
    – Rmano
    Mar 20, 2014 at 16:03

You must log in to answer this question.

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