Forum Replies Created
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.
Please check permissions to /tmp directory:
$ LANG=ENG ls -la / | grep tmp drwxrwxrwt 16 root root 4096 Mar 14 10:56 tmp
We are using ‘/tmp’ directory to exchange descriptors, it should be accessible by every user.
The cluster (shared) IP has to be fixed, this is the main part of the cluster. If the active server fails then the other one is starting and creating the same IP so users can reconnect.
The shared interface needs to be created on the common subnet for both cluster machines. Also, cluster machines need to be able to communicate
with each other. It could be the same subnet as above or the other one.
If this is required:
the active server in production datacentre and the standby in the DR centre
then I can suggest creating separate nodes for both cluster host. First, you need to create cluster after that I add nodes separately for both cluster machines. You have to remember to not execute ‘–clusterupdate’ after that as this command will synchronize node database, and you want to keep it separate.
That’s an interesting scenario.
The NoMachine Cluster was designed to solve a single point access problem for a multi-node environment. The cluster is providing a back-up server to take over traffic and reconnect users to their’s session on the remote nodes in case of disaster event on the current access point.
A good practice is to keep cluster servers in the one subnetwork, so they can establish between each other with is currently active: providing access to all nodes and with one is only monitoring first server status.
With have that on mind you can design your cluster in every way you want 😉
We cannot reproduce the problem with our laboratory.
Please provide as much detail as possible about the environment you are using to virtualize the machine and we will prepare ‘sandbox environment’ were you could reproduce the issue.
In particular we are inserting in the virtualization infrastructure (KVM, VMware, VirtualBox, etc) and the machine parameters (like CPUs, RAM and any option that could be important).
Please also provide exact NoMachine package version that you are using.
Also I am still not sure if you are accessing physical desktop on virtual machine or you are creating new virtual session.
Logs in nxnodes working directories do not contain any particularity error that could point the problem.
We need debug logs. Please enable debug level log in server.cfg and node.cfg files on the server.
Please also set SessionLogClean on 0. Then restart NoMachine and after issue occurs upload full var/log
directory to forum[at]nomachine[dot]com.
What Linux version are you using in the virtual machine?