This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: X: Authorization required, but no authorization protocol specified
- From: Markus Hoenicka <markus dot hoenicka at mhoenicka dot de>
- To: cygwin at cygwin dot com
- Date: Mon, 10 Aug 2015 09:41:38 +0200
- Subject: Re: X: Authorization required, but no authorization protocol specified
- Authentication-results: sourceware.org; auth=none
- References: <67ea3d1202eccadc3fc21e58af6ca4bf at mhoenicka dot de> <55C479DA dot 7000203 at dronecode dot org dot uk>
At 2015-08-07 11:26, Jon TURNEY was heard to say:
On 06/08/2015 17:56, Markus Hoenicka wrote:
I've upgraded my setup yesterday and ran into a problem running the X
server. X ran just fine before the upgrade, just like any X client I
threw at it. I'm aware that some defaults have changed in the couple
of
months since I upgraded, and I hope I've done everything the FAQ
recommends to accommodate these changes. However, no joy.
Starting the X server now is noticeably slower, regardless of how I
start it (Windows start menu, startx, or my hitherto preferred method
startxwin). Biggest problem though is that local X clients cannot
connect. The server output is like this:
$ startxwin /usr/bin/xterm
xauth: file /home/markus.hoenicka/.Xauthority does not exist
xauth: file /home/markus.hoenicka/.Xauthority does not exist
xauth: file /home/markus.hoenicka/.Xauthority does not exist
xauth: file /home/markus.hoenicka/.Xauthority does not exist
startxwin is just a shell script (based on the standard startx), which
invokes xauth to add an authorization cookie to ~/Xauthority (which is
also passed to the server using the -auth option)
The file ~/.Xauthority is created during startup, and it is empty
after the server shuts down. It does not make any difference if I
remove the empty file before restarting the X server.
It should have some (binary) content while the server is running, but
that seems to be failing to happen, for some reason.
I forgot to mention that while the server is running there is indeed
some binary content. The file is empty only after the server stopped.
As a workaround I can start XWin manually like this:
/usr/bin/XWin :0 -multiwindow
This works, of course, because this doesn't use -auth.
Yes, I just thought I'd mention that in case someone bumps into the same
problem. It might not be that obvious to the uninitiated.
However, I suppose the default behaviour of startx and startxwin was
not
intended to perform like this. Did I miss something obvious?
Indeed.
Is there anything unusual about your home directory?
Well, we use roaming profiles here at work. This has caused problems
before, both in Cygwin and non-Cygwin apps. I've modified
/usr/bin/startxwin like this:
$ diff /usr/bin/startxwin.orig /usr/bin/startxwin
138c138,139
< XAUTHORITY=$HOME/.Xauthority
---
# XAUTHORITY=$HOME/.Xauthority
XAUTHORITY=/cygdrive/c/localdata/<username>/.Xauthority
i.e. it now uses a local drive to store .Xauthority. With this change,
startxwin works without a hitch, and it is not any slower compared to
before the upgrade. I don't know what is particularly broken about my
$HOME as most Cygwin apps deal with it just fine:
$ cygpath -w $HOME
\\<serverpath>\home\<username>\Eigene Dateien\home\<username>
You might try modifying startxwin to remove the -q from xauth -q to
see if that reveals a bit more information.
regards,
Markus
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple