Forum Replies Created
December 30, 2020 at 13:20 in reply to: NoMachine 7.0.209 on Windows10 – cannot connect to due to “Error is 108” #31031
Thank you for taking the time to report this.
We reproduced the issue in our labs. Here is the relevant Trouble Report:
Please use the “Notify me” to know when a fix is available.December 23, 2020 at 15:43 in reply to: NoMachine 7.0.209 on Windows10 – cannot connect to due to “Error is 108” #30893
It looks like we cannot start ‘nxclient –monitor’ process:
13644 13644 2020-12-22 14:35:45 946.970 NXNODE WARNING! Process ‘C:\Program Files (x86)\NoMachine\bin\nxexec.exe –monitor –pid 1028’ with pid ‘13824/936’ finished with exit code 1 after 0,051 seconds.
Due to that problem we cannot make physical desktop available.
Could you please provide directory ‘.nx’ from home directory of current logged user?
Further logs weren’t requested because we did reproduce the problem on openSuse 15.1.
The Trouble Report opened to handle this issue is: TR12R09942.
After further investigation and tests in our labs, we verified that the nxserver daemon
has been restarted five times only. This is also confirmed by your logs.
Five attempts to start the nxserver daemon is the expected behaviour, therefore
the following Trouble Report is no longer valid:
We confirm instead the other problem:
The NoMachine error log file is filled with messages ‘Cannot assign requested address’
NoMachine server needs to be able to resolve localhost.
Usually when this is not possible, NoMachine prints that during the installation process for example:
NX> 500 ERROR: Cannot start NoMachine server. Resolve ‘localhost’ is
NX> 500 ERROR: not possible. Please check settings in the system
NX> 500 ERROR: hosts file or contact your system administrator.
But in your case the issues appears after the successful installation so it is not obvious what is going on.
We confirm the problem of producing redundant error message while
searching for free ports. The Trouble Report opened to handle this
issue is: TR12R09936.
It looks like we have also a problem with repeated restarting of
NoMachine server daemon. TR about this problem is: TR12R09937
NoMachine needs to be able to access the new host IP address. Please check if you can ping the new IP of your server host from your client host.
Good to know that executing that command fixed the problem, the logs confirmed that that was the problem.
In case the directory is owned by ‘root’, you could fix it by executing the command:
sudo chown -R nx /usr/NX/var/db/limits.
Hello matef and gabriele,
You should provide a path to nxserver
To remove those files you need
sudo rm -f.
Please check the whole directory:
sudo ls -la /usr/NX/var/db/limits/
To solve the problem you should remove the problematic file and execute
It will fix the database.
Before that please check the current permissions to that file:
ls -l /usr/NX/var/db/limits/sessions.vdesktop
and gather the logs:
nxserver --debug --collect
Send them to forum[at]nomachine[dot]com making sure to reference your topic.
ETS stands for Enterprise Terminal Server, it is the package installed on nx02.
‘load-average’ will prioritize nodes with the lowest current CPU usage.
It will not guarantee even session distribution.
I’m not sure how to check the part that all users have an account on all available nodes
You should check if every user that login on nx02 has a system account on nx01 and nx03.
session selected is available everywhere
You should check available nodes resources
nxserver --nodelist --resource
and compare it to
AvailableSessionTypeskey in server.cfg on nx02.
Make sure that session types requested by users are available on every node.
You could check session types for the already created session with the command:
By default, ETS is selecting the session node using a round-robin algorithm. We are creating a list of available nodes and following this list when creating the session for the user. If for some reason we cannot create a session on the first node on the list we go to the next one.
Please check that all users have an account on all available nodes and that session selected by the user is available everywhere.
You could also change selecting algorism to ‘load-average’ or ‘system-load’ by specifying them in LoadBalancingAlgorithm key
in server.cfg on ETS.
If you want to simply avoid creating a new session on the localhost please consider stopping local node (nxserver –nodestop localhost:4000). It will allow users to restore sessions but it will remove localhost from available pools of nodes.
NoMachine processes are connecting to each other by the localhost.
Please add also an exception for that. It could look like that:
iptables -A INPUT -p tcp -s localhost -j ACCEPT
The error “This node is running on a NoMachine server with a multi-node setup enabled” is printed when we are still detecting an active connection with the other multi-server. If ‘originally-assigned terminal server’ is down, it sometimes requires a few moments to close the connection.
Is there a way I can configure this to override the previous registration?
To be sure that remote node is no longer aligned with multi-server keys you have to remote access public keys. On Linux: ‘/var/NX/nx/.nx/config/authorized.’ for NX protocol and restart NoMachine Server on that node.
‘–strict-host-key-checking’ option is for automatically save the host key. A host key is a cryptographic key used for authenticating computers. This is the first step when connecting to a new host. In next step server detects that cannot access the terminal server Node with the public key, we have to log in to the remote node to add this key to get access to that host. We need privileged user credentials to do that.
It looks like KDE is not starting properly. It’s hard to say only from client side logs.
You should check possible error messages in the user’s home directory ‘.xsession-errors’ file and system logs. Also ‘clients’ file in
/usr/NX/var/log/node/F-C-<session ID>/could say what is going on with this application.
You could also try to start
custom session: console in virtual desktopand run KDE start command manually to check exact error message.