Forum Replies Created
-
Posts
-
The steps to generate the cookie are:
1) $ COOKIE=
ps -ef | md5sum | cut -f 1 -d " "2) $ sudo xauth -f /var/run/Xvfb-0.auth add :0 MIT-MAGIC-COOKIE-1 $COOKIE
3) $ xauth add :0 MIT-MAGIC-COOKIE-1 $COOKIE
We’ll update the article 😉
Check that you have set up your forwarding to port 4000. If you are connecting via NX, NXD listens on the default port 4000.
Bug confirmed. A Trouble Report is open (https://www.nomachine.com/TR12K04131). We’ve added a notification facility to all TRs now, so you can receive an email when the fix has been released.
I tried to verify the difference using the MacOS and Linux clients (4.6.8) connecting to CentOS 6.5 and the default NX server from the distribution
This indicates that you could be connecting to an older NX server, possibly 3.5.0. You are therefore connecting using a connection file created with (let’s say) NX Client 3.5.0, in which the type of the desktop (e.g. KDE, Gnome etc) is always saved in the connection settings. Selecting the desktop type was a pre-requisite in 3.5.0 before logging in, in version 4 you select after authentication.
when I reconnected and did “Reset login information and preferences”, suddenly the session list appeared. This worked with both clients to the same host.
This means that the check box is doing its job properly 🙂 You can see the remote sessions list because when resetting the connection configuration, the session type you have already set in your “old connecting file” gets removed. The client can’t automatically start an “unknown” session and hence you get the option to run a new virtual desktop session. Maybe you had selected to create a new desktop and stored this setting in the connection file. Resetting this setting now, you get the options to reconnect to an existing desktop (the session list). Knowing that, if you find any inconsistency please let us know.
If you prefer this behaviour, you can uncheck the box “Save this setting in the configuration file” when selecting the type of virtual session to start. This way you will see the session list and the option to start a new session.
When the NoMachine Client connects to a server 3.5 or to a server 4.0 which defines the Connection policy rules, it starts a new session if it can’t reconnect a session already running. There may be a problem with the detection of the session to reconnect. Precise information about the NoMachine software versions (client and server) will be helpful to debug the issue.
Hello Ian,
To connect to a 3.5.0 server from NoMachine client 4 you need to select the NoMachine login in the connection GUI. Steps are here:
https://www.nomachine.com/AR04J00627
Let us know that this fixes the problem.
Hi, NoMachine uses its own automatic update mechanism, currently in beta.
Hi, NoMachine uses its own automatic update system, currently in beta. This update system works the same on all platforms (including Windows and Mac) and has no system dependencies.
To update your installation:
– Run the NoMachine GUI from your Programs menu.
– Access the ‘Change server settings’ panel.
– Click on the ‘Software updates’ button (last little icon on right).
– Click ‘Check updates’.
Updates are only manual, at the moment, until the system will be considered ready for production use.
BG
Can you verify that you are indeed using 4.0.368 on the server side? There was a known bug that was supposedly fixed in the 4.0.368. Of course your problem can be unrelated, but we would like to be 100% sure it’s not the same.
What you need is the Workstation for Linux.
Any of the products from the Terminal Server range (e.g. Workstation or Terminal Server, https://www.nomachine.com/enterprise) allow to create virtual desktop sessions. The Workstation and all the Terminal Server versions work as terminal servers, by creating sessions running in the background. These are terminal servers, intended for the enterprise market.
Hi Lawrence, I noticed you are using 4.0.352 on the client side and 4.0.366 on the server side.
Can you update both to 4.0.367 (use the automatic updates ;-)).
It is likely to be related to a bug which we’ve fixed in the latest release, here: https://www.nomachine.com/TR12K04092.
This has been fixed in 4.0.367 (recently released).
Don’t forget to use the automatic updates to get the changes and let us know that everything worked 😉
Error: Connections to virtual desktops are disabled on this server.
It appears to be a problem which was just fixed with the release of 4.0.367. Can you update? Note that a fix for https://www.nomachine.com/TR11K04066 is not yet available. It will probably make the next update.
Ang, again the logs don’t show anything strange. If possible, can we send you a debug version for you to install? Let us know: issues[at]nomachine.com
BG
It sounds like the bug with domain users’ authentication for which a fix should be released very soon.
https://www.nomachine.com/TR11K04021
A quick check to see if it is this bug is to try logging in with a local account (if that’s possible).