Purpose: Help users deal with the problem if launching a Tk application reports:
Xlib: connection to "host.domain:0.0" refused by server Xlib: Client is not authorized to connect to Server Application initialization failed: couldn't connect to display "host.domain:0.0"
Well, at least you're not getting the dreaded message
You've successfully locked down your X server, and discovered that you've locked yourself out.
The most likely explanation is that you're not logged in as the same user as when you entered your name and password to the display manager or ran x11start (startx, whatever your command is that starts the X server). This isn't a catastrophe, as long as you can become that user. That user has a file called .xauth in the home directory that contains the required magic cookie that you need to access the display.
This is one of the few cases where there's actually an application for the xauth command. On the machine where you originally logged in, as the same user, do
xauth extract - $DISPLAY
and pipe the result of that into
xauth merge -
as the user you now are on the machine where you now are. Often the correct magic is
ssh -l USERID HOST xauth extract - $DISPLAY | xauth merge -
If you don't have ssh, try rsh or whatever you use to execute a remote command.
LES: That doesn't work for me on Ubuntu 10.10:
luc[231-0]/> xauth extract - $DISPLAY | xauth merge - xauth: error in locking authority file /home/luc/.Xauthority Exit 1 luc[232-1]/> ssh -l luc localhost xauth extract - $DISPLAY | xauth merge - xauth: error in locking authority file /home/luc/.Xauthority xauth: (argv):1: unable to read any entries from file "(stdin)" Exit 1
What worked for me (as root):
# cp /home/luc/.Xauthority /home/root/
I don't know if it's a good idea, but the problem went away.
Ah! This also works (just needs to be done once):
# xauth merge /home/luc/.Xauthority
D. McC: Or try simply running this:
KBK - Please don't. It's BAD MOJO. See X server insecure (must use xauth-style authorization).