Forum Replies Created
-
Posts
-
t-dome,
these “debug version of NX”, are custom builds we prepare on purpose with debug symbols and logs enabled in the components we suspect may have generated the problem. We can’t distribute these versions as standard because they would be really huge and because a component with logs enabled, depending on the component, may generate megabytes of logs per second. In the best case it would fill your disk or slow the machine to a crawl.
OK, makes sense. This will not make the client less secure, since there are obviously other ways to by-pass the check if one has access to the executable code.
Did you try to set:
ConnectPolicy autocreate=0,autoconnect=1,desktop=0
in the server configuration?
Be also sure that the first time you connect, you check ‘Save this setting in the configuration file’ in the GUI. Then disconnect and connect once again: you should now be able to reconnect the virtual desktop.
The .nxs file is in XML format. It contains user readable keys which names are intended to be self-explanatory.
To see how the .nxs file looks like, please open any of the connection files created from the NoMachine GUI. They are stored in the directory specified for Connections in the Player settings. For example on Windows, the .nxs files are stored by default here: %USERPROFILE%\Documents\NoMachine
Is the owner of the virtual desktop the same user who then connect to such virtual dekstop? We have found that in this case, disabling virtual desktop sharing in the server doesn’t make effect. Problem is tracked here:
You’ll notice none of their download links now work, is this due to them linking previously to the Version 3?
It is more because there is now a new website and the layout of the download section is changed. You should probably notify their webmasters so that they can update the links.
they say to specify ‘Unix’ and ‘GNOME’ for the connection, but in the new version 4 I can see no way of doing this
With client 4, it’s no more necessary to pre-configure the session: when you connect to server 3.5.0 you will have all the available session types listed.
About connecting to the server, did you read this article? It explains how to connect using the client 4 to a 3 server.
It seems to me that you are doing everything right. You configured the router to let the port 4000 go through, and also configured the router for the UDP port (if I was you I would try to disable UDP in the beginning and first ensure that the basic connectivity to the TCP port is OK, since this is what you essentially need). What exactly is not working now? Are the IP addresses correct? Can it be a firewall problem on the receiving machine?
About the documentation, maybe you are setting your expectations too high. We can explain how to use the software (that basically it is a matter of connecting to port 4000 and inserting the username and password) but you can’t expect the documentation to be a port forwarding and NAT traversal manual dealing with every possible router, firewall or network setup. Every software in this category provides a global directory and automatic NAT traversal. Without this is impossible for 99% of the users to deal with the required network configuration. I know you are knowledgeable enough to do everything yourself, but not all users are experienced network administrators or firewall specialists. We are obviously working on such automatic NAT traversal. While the software is hopefully good today for a corporate setting where there are professionals paid to solve this kind of configuration problems, at the present moment I would never suggest it to the wider consumer public. Probably you noted that we are not even trying to advertise it to such a audience. I don’t think extending the documentation would be of any help.t-dome,
we are aware of some possible problems occurring when using the system tools for authentication. A new way for authenticating will be available with the upcoming 4.1 release.
Can you uninstall, making sure you remove the /etc/NX folder and then reinstall? Does it fix it? It sounds like the same problem reported here:
This seems a X server reset at the login screen that is not caught by the node.
Explanation: After the login, the X server resets and closes all the connections by clients, including the NoMachine node process. Then the X server begin listening again, so the desktop environment can start. The node should try to connect again automatically but it is mistaking the reset.
Is this explanation correctly describing the problem? Can you please check if before and after the login screen the X server process id is still the same? You can do that using the ps command.
On the server do:
> ps auxwww|grep X
Then login. After the client disconnects, do again:
> ps auxwww|grep X
See if the pid of the X server process has changed.
We noticed that your logs report errors like:
Cannot retrieve status for service ‘nxservice’
This kind of errors occur when connecting as unprivileged user to a Windows host having UAC enabled. The correspondent trouble report is here: https://www.nomachine.com/TR11K04087 . The bug will be solved in the next release.
This problem anyway doesn’t explain why the connection to the Windows host is suddenly terminated. To investigate the problem we would need some more logs.
Please send the ‘ProgramData/NoMachine/var/log’ directory from the Windows server host to: forum[at]nomachine[dot]com.
Additionally, we need also the output of the ‘net user’ command. In order to get it please run a cmd console as administrator:
– Click the Start button Picture of the Start button.
– In the Search box type cmd.
– In the list of results, right mouse button click and choose to run the cmd application as administrator.
– In the cmd shell run command:
> net user gaoxing
Then send the output of the command to forum[at]nomachine[dot]com and possibly specify the username of the user who installed the server on the Windows host.
INED,
since you have a valid subscription, please open a Support Enquiry from your Customer Area and redirect your questions to the proper Support channel.
Hi plop38746,
“When I follow the article instruction to build the module I get the error posted below.”
please do not use ‘sudo make’ because sudo drops the PWD environment variable and causes compilation problems. We have just updated https://www.nomachine.com/AR12J00658 to state it more clearly.
Additionally we found that there is a compilation error (the fix will be shipped with the new packages that we will release soon).
You can fix the problem manually:
IMPORTANT: Let’s assume that NoMachine is installed in /usr/NX.
1. Navigate to /usr/NX/share/src/nxusb
2. Edit ‘vhub.h’ file in your favourite text editor.
If you’re using vi or vim you can skip directly to the line in question:$ vim vhub.h +60
3. Edit the 60th line that currently is:
enum { VHUB_NUM_PORTS = USB_MAXCHILDREN > 15 ? 15 : USB_MAXCHILDREN };
to have:
enum { VHUB_NUM_PORTS = 15 };
4. Save the changes in file (:wq in vim).
5. You are now ready to compile the module.
6. Be sure that you run ‘make’ as non-privileged user:
$ make
If the build fails due to permission problems, run the following command:
$ sudo rm -rf /usr/NX/share/src/nxusb/include/linux
And then retry:
$ make
If there are still problems with permissions, run the compilation as root. Use ‘su’ and then run the ‘make’ command.
Isabel,
From the error you are getting, a possible explanation is that you are using the wrong IP address to connect from the first computer to the second. Please do the following for verifying that.
1. On the first computer, run a cmd console (click the Start button Picture of the Start button. In the Search box, type cmd, and then, in the list of results, double-click on the cmd application).
2. In the cmd console run the following command:
> ipconfig
3. Do the same on the second computer.
4. Copy&paste the output you get on the first and second computer and send us via mail at: forum[at]nomachine[dot]com. For privacy, it’s better you don’t post the IP addresses in a public forum