From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53757 invoked by alias); 26 Mar 2015 19:12:20 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 53749 invoked by uid 89); 26 Mar 2015 19:12:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: out2-smtp.messagingengine.com Received: from out2-smtp.messagingengine.com (HELO out2-smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Mar 2015 19:12:17 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B6E5920AC7 for ; Thu, 26 Mar 2015 15:12:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 26 Mar 2015 15:12:15 -0400 Received: from [192.168.1.102] (unknown [31.51.205.126]) by mail.messagingengine.com (Postfix) with ESMTPA id 125516801C7; Thu, 26 Mar 2015 15:12:14 -0400 (EDT) Message-ID: <55145A0D.4010406@dronecode.org.uk> Date: Thu, 26 Mar 2015 20:39:00 -0000 From: Jon TURNEY Reply-To: cygwin@cygwin.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cygwin@cygwin.com CC: Andrew DeFaria Subject: Re: X11Forward and xauth problems References: <55108046.1070206@dronecode.org.uk> <55115B29.8000904@dronecode.org.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00469.txt.bz2 On 25/03/2015 17:40, Andrew DeFaria wrote: > Prediction: This problem probably will end up having something to do > with the permissions and file system that ~/.Xauthority resides on, > which is, I believe, a NetApp. This file system is the file system for > the Linux Home directories (Windows "home" directories are somewhere > else). In an attempt to have a transparently workable environment I set > my Cygwin home directory to access the same directory my Linux servers > use for the home directory - this NetApp. If you need more information > about that then let me know and perhaps tell me how I can get that. This seems very plausible. If I am understanding you correctly, ~/.Xauthority is the same file on the NetApp at both ends. I think perhaps that is somehow the cause of the problem. The sequence of actions is something like: - startx(|win) generates a random cookie and stores it in ~/.serverauth. and uses that file as the server -auth option - it also uses 'xauth add' to put that cookie into ~/.Xauthority for the display (e.g. :0) - ssh reads that cookie out of ~/.Xauthority using 'xauth list' and sends it to the far end - sshd tries to store that cookie using xauth for the proxy display (e.g :10) Reading the source of xauth [1], it does try to lock the ~/.Xauthority file for up to 20 seconds before giving up, which perhaps corresponds to the delay you see? However, the "unable to link authority file .Xauthority, use .Xauthority-n" message indicates that the working file .Xauthority-n cannot renamed as .Xauthority (xauth tries both to hard-link it as .Xauthority, and to rename it) Of course, sshd doesn't understand it's helpful advice to use a different filename, so things don't work out so well. :) Given that it works the first time, when there is no existing ~/.Xauthority, perhaps the NetApp doesn't permit this file to be renamed over an existing file, for some reason? You can tell startx to use a different file by using the XAUTHORITY env var, so setting that to something like ~/.Xauthority-$HOSTNAME might be a workaround. (Some googling on 'Xauthority hostname nfs' might be informative) Or editing startx and changing enable_xauth to 0 might also be a workaround. > As you can see with my current ~/.Xauthority file things don't work. But > if I remove them, the ~/.Xauthority* files one is created at the next > login and everything works fine. Log out and back in however and it > breaks again. >>>> If you want this to work, you will now (since X server 1.17) need to >>>> start the server with the option '-listen tcp'. >>> >>> Restarted Xwin with -multimonitor and -listen tcp. Now I get: >> >> Sorry for any ambiguity, but you have misunderstood what I wrote. >> >> If you want explicitly setting DISPLAY and allowing access using xhost >> to work, you must start the server with the option '-listen tcp'. > > Sorry I misunderstood. This works for me and is a work around. But I > wish I could get that xauth thing working correctly. Good. [1] http://cgit.freedesktop.org/xorg/app/xauth -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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