On 11/04/2017 06:23 PM, Robert Kudyba wrote:
The server that works, that's where the NFS share is mounted. The workstation that fails, it uses the mounted NFS share from the server that works.
You mean the server that works is where the NFS share is mounted *from* - so for the server, this is a local filesystem, while for the workstation, it's a remotely mounted NFS file system, right?
I agree with Uli - you should try mounting it in a hard way so that it's always available. In theory, permissions problems could also be at fault, although you're clearly able to manipulate the file manually, so that's not a likely cause.
cat session.log Error: Aborting session with 'Unable to open display 'nx/nx,options=/tmp/.x2go-localguy/C-localguy-137-1509136412_stDXFCE_dp32/options:137''.
Well, interesting. Is this file still available? If yes, what is its content?
Also, if available, the "clients" file would be interesting.
If I interpret that correctly, nxagent isn't able to open its own internal display... which is fairly odd. It doesn't seem to be related to the remote client-side display, but the X server that is part of nxagent (and thus opened in nxagent.) Don't worry, if that doesn't make sense, nxagent's infrastructure is quite complicated... c.f., the second diagram on https://en.wikipedia.org/wiki/NX_technology#Technical_details_of_legacy_vers...
And here's the debug log from the nightly build client:
[...] Info: Forwarding X11 connections to display '/private/tmp/com.apple.launchd.XQbZF46YQZ/org.macosforge.xquartz:0'.
Session: Session started at 'Sat Nov 4 13:06:03 2017'.
Okay, at least the cookie fetching problems on OS X are gone with that version. Again, this wasn't a "real" problem even before this fix, since a fake cookie would be generated which is (mostly) just as good.
Mihai