X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:reply-to:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=NU+N38+2wakfmH6M gcO762e1spXT+ES436aVn+OCo/oqo6Esj90oWufw9Rhw/h8AHN30TsHliLEtcq7S 5CNCjO8gMbOCBFAcwcMw0O039HmPH0AyTD+in8cU9LY+vtkGx6OFgeSKk7gnlKrZ cQI/rc9quOZVoYp6bKQxq9w/Cj0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:reply-to:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=default; bh=xtF//VcvdRPG3HmUVyMv8m UbHlY=; b=UYYmoeqggtLxN2yYFf9IjsTvj5JZNwcs8HWLULG9YOV+FtNNq1igGB vMYRDUWw4gcG3e0+1Hw0MP8MdLZhus51Z0iqkKOG22AEXVUz6xpyqR++OSyhzlxS 7JtWGhFM6ao/yGfzpK7DNO4a7VoAASuWFWpQUfvhq5cpGzFEKOrUE= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 Message-ID: <55145A0D.4010406@dronecode.org.uk> Date: Thu, 26 Mar 2015 19:12:13 +0000 From: Jon TURNEY Reply-To: cygwin AT cygwin DOT 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 AT cygwin DOT com CC: Andrew DeFaria Subject: Re: X11Forward and xauth problems References: <55108046 DOT 1070206 AT dronecode DOT org DOT uk> <55115B29 DOT 8000904 AT dronecode DOT org DOT uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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