Introduction

Welcome to the NoMachine Enterprise Cloud Server Cluster - Installation and Configuration Guide v. 8 or later. For sake of simplicity we will refer in this guide also to 'ECSC' (which stands for Enterprise Cloud Server Cluster) or to a more general 'Cloud Server' which applies to all products of the Cloud Server family.

 1. NoMachine Cloud Server Installation and Configuration Guide

The Cloud Server family of products offer four differents kind of servers tailored for different business sizes: Small Business Cloud Server, Cloud Server, Enterprise Cloud Server and Enterprise Cloud Server Cluster.

What is NoMachine Enterprise Cloud Server Cluster for?
NoMachine Enterprise Cloud Server Cluster works as a single point of access to multiple subsystems globally distributed and running NoMachine server installations or Unix-like operating systems for which we don't build a native package ('Foreign X Servers'). It can create a scalable infrastructure with multi-level nodes, by adding Cloud Servers as nodes.

It is designed to be used in conjunction with a second Enterprise Cloud Server Cluster, in order to set-up a failover cluster to grant high available access to the nodes. The cluster must be configured or none of the two servers will accept connections. Once configured the cluster and defined the primary and secondary roles ('master' and 'slave'), the primary server will start accepting connections. If contact with the secondary server is lost for any reason, the server will still accept connections but the failover mode will be not available.

Available for Linux, macOS, Windows, the Enterprise Cloud Server Cluster provides access to its nodes, (previously called 'child servers') via browser (thanks to its built-in web server) or via NoMachine client.

Building your centralized NoMachine architecture
A NoMachine Cloud Server is fully operative once installation is completed.

Then add your node(s) to the Cloud Server. These nodes can be:

- Any of the standalone NoMachine servers like Enterprise Desktop, Workstation, Small Business Terminal Server and Terminal Server.

- A NoMachine Enterprise Terminal Server or Enterprise Terminal Server Cluster which in turn manages a multi-node environment made of NoMachine Enterprise Terminal Server Nodes.

- Another NoMachine Cloud Server which in turn rules its own nodes (multi-level infrastructure).

- A Foreign X Server, i.e. a Unix-like host running an unsupported O.S. for which we don't build native packages.

NoMachine servers added to the main Cloud Server are first-level nodes.

High-Availability
Two NoMachine Enterprise Cloud Server Cluster need to be set-up in a high-availability failover cluster. This grants continuous access availability to the nodes.

A Graphical Interface
A Cloud Server package includes the NoMachine User Interface which provides the graphical interface (Server Settings) for administering the Cloud Server and its services.

The Cloud Server comes also with a client UI for running sessions and connecting to other remote NoMachine servers. Connecting by the client UI can be also used by administrators to add, modify and remove nodes and to administer the nodes remotely. This remote server administration UI mirrors the local NoMachine server UI and allows to perform the same operations.

A guide to the NoMachine server UI is available in the 'Configuration' section at: https://www.nomachine.com/all-documents

A tutorial about how to add nodes to a Cloud Server via UI is available at the same URL above in the 'Tutorials' section.

 1.1. About This Guide

Document Conventions and Important Notices
The following conventions are used in this guide:

BaseDirectory
is the base directory where the NoMachine binaries and libraries are installed.
By default, BaseDirectory is:
/usr on Linux
C:\Program files for 64bit packages on 64bit systems, C:\Program files (x86) for 32bit packages on 64bit systems
/Applications on Mac.

InstallationDirectory
is: BaseDirectory/NX on Linux, BaseDirectory/NoMachine on Windows and BaseDirectory/NoMachine.app on Mac.

The command line interface
The NoMachine server program (nxserver) has a command line interface to execute operations.

You need to be a privileged system user to access most of these functionalities. Run these commands from an xterm or similar on Linux and macOS using the sudo utility or as root (and without 'sudo').

On Windows, run them from a command prompt (cmd.exe) executed as administrator.

On Linux and macOS, invoke the 'nxserver' program from /etc/NX, for example:

$ /etc/NX/nxserver --help

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --help

The 'nxserver --help' command displays the list of all the available commands, their options and their description.

Online Resources
Visit the NoMachine Support Area to access a variety of online resources included the NoMachine Forums, tutorials and FAQs: https://www.nomachine.com/support

Find a list of all documents and tutorials for v. 8: https://www.nomachine.com/all-documents

Use the Knowledge Base search engine to access articles, FAQs and self-help information: https://kb.nomachine.com

Leave Feedback About This Guide
Our goal is to provide comprehensive and clear documentation for all NoMachine products. If you would like to send us your comments and suggestions, you can use the contact tool available at https://www.nomachine.com/contact-request, selecting Web Quality Feedback as your option.

 2. Install, Update or Remove

This section will guide you through all the steps to install, update and uninstall a Cloud Sever in your environment. Please consult the appropriate section for the operating system you are installing on. There are two ways to update your installations: via the automatic updates from our repositories or updating manually using packages.

 2.1. Prerequisites

Supported Operating Systems
Windows 32-bit/64-bit Vista/7/8/8.1/10/11
Windows Server 2008/2012/2016/2019/2022

Mac OS X Intel 64-bit 10.9 to 10.11/macOS Intel 10.12 to 12/macOS Silicon 11/12

Linux 32-bit and 64-bit
RHEL 6.0 to RHEL 9
CentOS 6.0 to CentOS 8.5
CentOS Stream 8 to CentOS Stream 9
SLED 11 to SLED 15
SLES 11 to SLES 15
openSUSE 11.x to openSUSE 15.x
Fedora 10 to Fedora 36
Debian 5 to Debian 11
Ubuntu 8.04 to Ubuntu 22.04

Hardware requirements
Intel Core2 Duo or AMD Athlon Dual-Core or equivalent
1 GB RAM
Network connection (either a LAN, or Internet link: broadband, cable, DSL, etc...)
Size required on disk:
Windows 210 MB
Linux 195 MB
Mac 180 MB

Software requirements
1) We recommend using a Cloud Server v. 8 with NoMachine server v. 8 installed on the nodes in order to grant a fully functional set-up with all the available features (e.g. the new inverse connection).

Although a Cloud Server v. 8 can work with nodes v. 7 and vice-versa, it's advisable to limit the use of mixed versions to the time necessary in order to complete the upgrade of the whole environment. Best practice is to upgrade all nodes first and then the cloud server.

2) NoMachine client v.6 and v.7 can be used to connect to a Cloud Server v. 8, but it's strongly advisable to use client v. 8 to benefit from all the new features, included the remote server administration UI.

3) In order to connect by NoMachine to the physical desktop of a Linux Cloud Server host, a desktop environment must already be installed. This applies also to headless Linux machines.

 2.2. Windows Installations

INSTALL
Download the package for Windows from the NoMachine web site and install it by double-clicking on the icon of the executable: a setup wizard will take you through the installation. Accept to reboot the machine, this is mandatory for completing the installation.

If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

To install the package in silent or very silent mode from a CMD console, run respectively:

> nomachine-packageName_packageVersion.exe /silent
or:
> nomachine-packageName_packageVersion.exe /verysilent 

Then reboot the machine:

> shutdown /r /t 10 /c "your comments here" 

To specify a non-default installation directory, use:

> nomachine-packageName_packageVersion.exe /SILENT /DIR="X:Target_directory"
or:
> nomachine-packageName_packageVersion.exe /VERYSILENT /DIR="X:Target_directory" 

UPDATE
The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. While updating the Cloud Server, users will be not able to access the nodes. Users can connect later to recover their sessions on any of the nodes.

There are two ways to update your current installation:

1. Automatic updates

   You can update your installation from our repositores. Just run the NoMachine UI from your Programs Menu and access the Settings -> Server -> Updates panel and click on the 'Check now' button. Follow the prompts to continue the update.

   NoMachine has the automatic check for updates enabled: it will check by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.

   Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.

   Detailed instructions for configuring the Automatic Updates are available in a separate document in the 'Configuration' section at: https://www.nomachine.com/all-documents .
2. Update with NoMachine packages
   Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.

   If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

UNINSTALL
You can uninstall the Cloud Server from the Windows Control Panel and the 'Program and Features' in Windows Vista, 7, 8 ,10 and 11. Find the NoMachine program in the list of installed programs and choose to uninstall it.

On Windows 10 and 11, right click on Start button, choose Apps and Features and scroll down to 'NoMachine'. Select it and uninstall. Otherwise open the search box, type 'Control panel' to open it. Then go to Programs, Programs and Features and uninstall NoMachine from there.

On Windows 8 you can use the Search box from the Charms bar on the right side of the screen: type Control Panel to open it. Then access the Programs - 'Uninstall a program' panel.

On Windows 7 and Vista, click on the Start button and click to open the Control panel from the Start menu. Then access panel 'Programs and Features' .

Reboot is mandatory to complete the uninstalling process.

To uninstall from a CMD console, move to C:/ProgramData/NoMachine/var/uninstall/ (if you are on Vista/7/8/10/11). Then run:

> unins000.exe /silent
or:
> unins000.exe /verysilent

Uninstalling is completed when your command prompt is back. Then reboot the machine:

> shutdown /r /t 10 /c "your comments here"

 2.3. Mac Installations

INSTALL
Download the DMG package from the NoMachine web site. Double-click on the disk Image to open it and see the package icon. Then double-click on the package icon to install the program: the installer will take you through the installation.

If you own a customer license we recommend you download the package from your Customer Area: https://www.nomachine.com/support#login.

To install from the command line, run:

$ NXMOUNTDIR=$(echo `hdiutil mount nomachine-cloud-server_version.dmg | tail -1 | awk '{$1=$2=""; print $0}'` | xargs -0 echo)
$ sudo installer -pkg "${NXMOUNTDIR}/NoMachine.pkg" -target /

UPDATE
While updating the Cloud Server, users will be not able to access the nodes. Users can connect later to recover their sessions on any of the nodes.

There are two ways to update your current installation:

1. Automatic updates
   You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and access the Settings -> Server -> Updates panel and click on the 'Check now' button. Follow the prompts to continue the update.

   NoMachine has the automatic check for updates enabled: it will check by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.

   Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.

   Detailed instructions for configuring the Automatic Updates are available in a separate document in the 'Configuration' section at: https://www.nomachine.com/all-documents .

2. Update with NoMachine packages
   Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.

   If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

UNINSTALL
To uninstall the Cloud Server drag and drop NoMachine from Applications to trash or select 'Move to trash' from the mouse button menu. This will uninstall all the NoMachine software.

To uninstall from command line, it's enough you remove the NoMachine application directory:

 $ sudo rm -rf /Applications/NoMachine.app

 2.4. Linux Installations

Installing for the first time
You can install, update and uninstall using the graphical package manager of your Linux distribution or from command line by running commands from an xterm or similar with the sudo utility, or as root user if you don't have sudo installed. Instructions below refer to installation by command line.

If you own a customer license we recommend you download the package from your Customer Area: https://www.nomachine.com/support#login.

Successive updates
The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. This implies that all running sessions are terminated during the update procedure and cannot be recovered later. This applies to updates made by using NoMachine packages and to automatic updates from NoMachine repositories.

There are two ways to update your current installation:

1. Automatic updates
   You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and access the Settings -> Server Updates panel and click on the 'Check now' button. Follow the prompts to continue the update.

   NoMachine has the automatic check for updates enabled: it will check by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.

   Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.

   Detailed instructions for configuring the Automatic Updates are available in a separate document in the 'Configuration' section at: https://www.nomachine.com/all-documents .

2. Update with NoMachine packages
   Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.

   If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

 2.5. RPM Packages

If you want to install to default location, namely /usr/NX/:

INSTALL

# rpm -ivh <pkgName>_<pkgVersion>_<arch>.rpm
To find out which NoMachine package you have installed (you will get the full name of the package), run the following command:
# rpm -qa | grep nomachine

UPDATE

# rpm -Uvh <pkgName>_<pkgVersion>_<arch>.rpm

UNINSTALL

# rpm -e nomachine-enterprise-cloud-server-cluster

For non-default locations, for example /opt/NX:

INSTALL
# rpm -ivh <pkgName>_<pkgVersion>_<arch>.rpm --prefix /opt
UPDATE
# rpm -Uvh <pkgName>_<pkgVersion>_<arch>.rpm --prefix /opt
UNINSTALL
# rpm -e nomachine-enterprise-cloud-server-cluster

 2.6. DEB Packages

If you want to install to default location, namely /usr/NX/:

INSTALL

$ sudo dpkg -i <pkgName>_<pkgVersion>_<arch>.deb
To find out which NoMachine package you have installed (you will get the full name of the package), run the following command:
$ dpkg -l | grep nomachine

UPDATE

$ sudo dpkg -i <pkgName>_<pkgVersion>_<arch>.deb

UNINSTALL

$ sudo dpkg -r nomachine-enterprise-cloud-server-cluster

For non-default locations, for example /opt/NX:

INSTALL
$ sudo NX_INSTALL_PREFIX=/opt dpkg -i <pkgName>_<pkgVersion>_<arch>.deb
UPDATE
$ sudo NX_INSTALL_PREFIX=/opt dpkg -i <pkgName>_<pkgVersion>_<arch>.deb
UNINSTALL
$ sudo dpkg -r nomachine-enterprise-cloud-server-cluster

 2.7. TAR.GZ Packages

If you want to install to default location, namely /usr/NX/, ensure that package is placed there.

INSTALL

$ cd /usr
$ sudo tar xvzf <pkgName>_<pkgVersion>_<arch>.tar.gz
$ sudo /usr/NX/nxserver --install

UPDATE

$ cd /usr
$ sudo tar xvzf <pkgName>_<pkgVersion>_<arch>.tar.gz
$ sudo /usr/NX/nxserver --update

UNINSTALL

$ sudo /usr/NX/scripts/setup/nxserver --uninstall
$ sudo rm -rf /usr/NX

For non-default locations, for example /opt/NX:

 INSTALL
$ sudo NX_INSTALL_PREFIX=/opt /usr/NX/nxserver --install
UPDATE
$ sudo NX_INSTALL_PREFIX=/opt /usr/NX/nxserver --update
UNINSTALL
$ sudo /opt/NX/scripts/setup/nxserver --uninstall
$ sudo rm -rf /opt/NX

 2.8. Installing the License (for Customers)

Customers' packages
include a temporary (30 days) server.lic file for evaluation.
Such license file has to be replaced with the customer's license file acquired from NoMachine.

IMPORTANT:
The Cloud Server will cease to work once the license is expired.
Nodes with an expired license are still shown in the UI but their status is marked as 'failed' since they are unable to accept connections.
Please contact your NoMachine provider or the Support Team for license renewal options.

Installing the license can be done via the NoMachine UI in Settings -> Server -> Updates panel: click on 'Server subscription' to read the current license file.

Click on 'Update subscription' at the bottom right to upload and install a new license file. You will be requested to log-in with a privileged account (administrator) to perform such operation.

How to deploy server.lic on remote nodes via UI from a single point of access

Open the NoMachine client interface from a computer, connect to the cloud server, select the node and right mouse click to open the menu.
Choose 'Server admin' and login as administrator to the node when requested.
Choose 'Updates' in the right menu of the UI, eventually scroll down on the right side to reach the 'License information' section. Click on 'Server subscription' to read the current license and click on the 'Replace' button to upload and install the new one.

How to install server.lic from command line

To install the license from command line use the 'nxserver --subscriptionset' command.

On Linux and macOS:

$ sudo /etc/NX/nxserver  --subscriptionset path_to_server.lic

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --subscriptionset path_to_server.lic

To verify that server.lic is correctly in place and check its validity, run the nxserver --subscriptioninfo and --version commands.

On Linux and macOS:

$ sudo /etc/NX/nxserver --subscriptioninfo
$ sudo /etc/NX/nxserver --version

on Windows, open a CMD console as administrator and:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --subscriptioninfo
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --version

How to deploy server.lic on remote nodes from command line and from a single point of access

Upload the license files on a NoMachine Cloud Server.

Execute the 'nxserver --subscriptionset' command by specifying the node where the license has to be installed.

On Linux and macOS:

$ sudo /etc/NX/server --subscriptionset path_to_server.lic --target NODE

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --subscriptionset path_to_server.lic --target NODE

NODE can be in the node:port format or the name of the node (only for first level nodes) or the uuid of the node. Command above can be automated in a script that reiterates all the license files to install one by one on each node. The nodes must be already added to the main server.

 3. Add a Node to the Cloud Server and Configure it

A NoMachine Cloud Server allows to centralize the access to server subsystems, which are independent and globally located. In case of the Enterprise Cloud Server Cluster, these subsystems can be NoMachine servers ('nodes') or the so called 'Foreign X Servers', i.e. Unix servers which offer SSH connectivity and a X-windows based environment but don't have the NoMachine software installed.

The Cloud Server, we can call it the main server or the root server, can add a new server (node) to the multi-host infrastructure at any moment and without business discontinuity. It then becomes the parent server of that node.

Connection between Cloud Server and a node can be:
- direct or
- inverse

We speak about direct connection when the Cloud Server opens a connection to the node. Inverse connection is instead when it's the node that establishes the connection to the Cloud Server. This last way is necessary when the Cloud Server cannot connect directly to the node.

The method used by the Cloud Server to route the client connection to the node can be:
- Tunnel or
- Forward

With the Tunnel method, the client traffic is relayed through the Cloud Server to the node. This is the default method and allows to connect to nodes behind NAT or a firewall. When tunneling the connection, the Cloud Server opens a TCP connection and a UDP channel for real time communication of multimedia data. The Forward method is possible only when clients can connect directly to the node, for example because they are part of the same LAN or VPN. Administrators can configure the Cloud Server to use the Tunnel method as a fallback, if the Forward method fails for whatever reason.

One of the most common scenarios, suitable for example for any organization, is to use a Cloud Server to provide access to computers running the Enterprise Desktop so that users can have access to their desktops, as if they were sitting in front of that computer.

Nevertheless, any kind of server (except the free version of NoMachine) can be added to the Cloud Server, e.g. the Workstation or the Terminal Server or even the Enterprise Terminal Server with its Terminal Server Nodes.

It's also possible to add multiple NoMachine Cloud Servers to the main server (only Enterprise Cloud Server and Enterprise Cloud Server Cluster support adding on other Cloud Servers) building in this way a multi-level infrastructure (hierarchy) for more complex architectures. The main server is the top-level server which rules the whole hierarchy, the other Cloud Servers are multi-tier subsystems, which in turn can be parent servers of other nodes.

We call first-level nodes those servers that are directly added to the main Cloud Server, second-level nodes are added to a first-level Cloud Server node and so on. All servers are structured in a hierarchy. Servers' hierarchies can be built from the main Cloud Server (Cloud Server-to-node) or from the node that is going to be added (node-to-Cloud Server), we call it 'inverse node'.

 3.1. Adding NoMachine Servers as Nodes

Nodes can be added to the Cloud Server setup in the following ways.

Direct connection, Cloud Server to node:
- via the NoMachine server UI, opened on the Cloud Server or
- from command line in a console opened on the Cloud Server host

Inverse connection, node to Cloud Server:
- via the NoMachine server UI, opened on the node or
- from command line in a console opened on the node host.

Default settings and configurations

By default the node is added with the following settings which are suitable for most cases.

1) Connection between the Cloud Server and its node uses the NX protocol on port 4000.

2) NoMachine client connections are tunneled to the nodes by the Cloud Server.

3) Users can connect directly to the IP or hostname of the node. this can be forbidden by configuring the node.

4) A separate authentication on the node (optionally with a different account) is not enabled.

5) Access as desktop sharing guest to the Cloud Server and to the nodes is not enabled.

6) Once connected to the main Cloud Server, users can manually select to which node connect. The UI has two view modes to list only first-level nodes or all levels.

All the default settings can be modified.

How to add the nodes via UI

To add nodes via NoMachine UI, login as Administrator on Windows, root or a 'sudo' user on Linux and macOS to enable changes in the UI. As an alternative, a normal user can become a 'NoMachine administrator'. I.e this user will be entitled to add and manage NoMachine nodes, but this will not affect his/her system privileges. Such user must be NoMachine administrator on the Cloud Server and on the nodes.

A NoMachine administrator is a valid account having special rights for NoMachine. Being a NoMachine administrator doesn't affect system privileges of that user. To assign such NoMachine privileges to an existing system user (USERNAME), execute the following command on the main Cloud Server host.

On Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --administrator yes

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --useredit USERNAME --administrator yes

Give a name to the Cloud Server

A name must be always assigned to the Cloud Server. To do that, enter the Cloud Server administrator's UI, access the 'Nodes' panel and provide a name in the 'Server name' field.

The server name is global, i.e. it will be displayed for all nodes of that Cloud Server.

Add the node from the Cloud Server host via UI (direct connection)

The node is added with default settings which are suitable for most cases.

There are two ways to add a node via User Interface.

First way

Open the client UI on your device, connect to the Cloud Server as system administrator or as NoMachine administrator. Once connected, mouse click on 'Edit' button on the top bar of the UI and choose 'Add node'. Give a name to the node and its IP or hostname.

You will be then requested to login to the node as system administrator in order to complete the operation.

This is the same flow used in v. 7.

Second way

Open the Settings -> Server -> Nodes panel on the Cloud Server host and click on 'Add'. Provide your administrative credentials on the Cloud Server to proceed and give a name to the node and its IP or hostname.

You will be then requested to login to the node as system administrator in order to complete the operation.

Such way can be used also remotely. Open the UI on your device, select the connection to the Cloud Server, mouse click and select 'Server admin', then follow the same steps illustrated above. 'Server admin' will open the remote server administration UI which mirrors the local NoMachine server UI and allows to perform the same operations.

By default, the communication protocol between Cloud Server and node is 'NX' on port 4000. In the same panel, you can choose to use SSH instead. Connection will be established from the Cloud Server to the node (direct connection).

Default settings will suffice for the majority of environments. It is possible to configure extra details, always via the UI or modify them later.

For a step-by-step tutorial, consult https://www.nomachine.com/adding-nodes-to-nomachine-cloud-server-via-the-nomachine-user-interface

When the Cloud Server cannot reach the node, for example because it is in a DMZ zone, it's possible to establish an inverse connection from the node to the Cloud Server. To do that, it's necessary to be on the node and add it to the Cloud Server. This can be done via UI, either the Server UI available on the node or the remote server administrator's UI.

Add the node to the Cloud Server via UI (inverse connection)

By design and for improved security reasons, it's not possible to establish the inverse connection from the Cloud Server.

Open the UI on the node host and open the Settings -> Server -> Clouds panel. Then click on 'Add': you will need to provide administrative credentials to complete the operation. Give a name the node and provide the IP or hostname of the Cloud Server.

Such way can be used also remotely. Open the UI on your device, select the connection to the node, mouse click and select 'Server admin', then follow the same steps illustrated above. 'Server admin' will open the remote server administration UI which mirrors the local NoMachine server UI and allows to perform the same operations.

By default, the communication protocol between the node and the Cloud Server is 'NX' on port 4000. In the same panel, you can choose to use SSH instead. Connection will be established from node to the Cloud Server (inverse connection).

Default settings will suffice for the majority of environments. It is possible to configure extra details, always via the UI or modify them later.

To use the remote server administrator's UI you can create a connection to the node. Then mouse click on the connection and choose 'Server admin'. Login as system administrator or as NoMachine administrator.

For a step-by-step tutorial, consult https://www.nomachine.com/adding-nodes-to-nomachine-cloud-server-via-the-nomachine-user-interface

How to add the nodes from command line

On Linux and macOS, open a terminal and execute commands as 'root' or 'sudo' user. On Windows, open a CMD console as administrator.

Add the node from the Cloud Server (direct connection)

On the main Cloud Server host, execute the 'nxserver --nodeadd' command. On Linux and macOS:

$ sudo /etc/NX/nxserver  --nodeadd IP_of_NODE --node-name NAME_of_NODE

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeadd IP_of_NODE --node-name NAME_of_NODE

IP_of_NODE is the IP or hostname of the node to be added to the Cloud Server. It will become a first-level node.
NAME_of_NODE is the name to be assigned to that node. Assigning a name to the node is mandatory.

The complete list of options for the 'nxserver --nodeadd' command is available in the server usage ( /etc/NX/nxserver --help).

What is the node UUID

Once the node is added, it is assigned with a name, a NODEIP/Hostname:PORT pair for example testdrive.nomachine.com:4000, and a unique string identifier, UUID, for example: 53532db3-0626-4074-ae50-a87ab1f84538

To retrieve the UUID, use the 'nxserver --nodelist --extended' command.

When executing commands on the Cloud Server to manage the node, it's preferable to specify the node by its UUID.

First level nodes can be also specified by using their node name or NODEIP/Hostname:PORT pair. This information is available in the output of the 'nxserver --nodelist' command.

Add the node to the Cloud Server (inverse connection)

On the node host, execute the 'nxserver --serveradd' command. On Linux and macOS:

$ sudo /etc/NX/nxserver --serveradd IP_of_Cloud_Server    --node-name NAME_of_NODE

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --serveradd IP_of_Cloud_Server  --node-name NAME_of_NODE

IP_of_Cloud_Server is the IP or hostname of the Cloud Server to which the node will be added.
NAME_of_NODE is the name to be assigned to this node.
Assigning a name to the node is mandatory.

 3.2. Listing, Editing, Starting/Stopping and Removing Nodes

These operations can be done via UI from 'Nodes' and 'Clouds' server settings. Alternatively, you can find below commands to list the nodes, edit a node, stop and start it and remove it for both Direct and Inverse connections.

Listing the Nodes from the Cloud Server

On Linux and macOS:

$ sudo /etc/NX/nxserver --nodelist

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --nodelist

The output of 'nxserver --nodelist' reports by default only the list of first-level nodes. In order to display a multi-level list of nodes (not only first-level nodes) use option '--all' . Options '--all' and '--tree' used together provide a graphic representation of the multilevel infrastructure.

To print extended information, such as the unique identifier of the node (UUID), its server type and version, use the --extended option. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodelist --extended
$ sudo /etc/NX/nxserver --nodelist --all --extended

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodelist --extended
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodelist --all --extended

The output of this command will provide the following additional information:
UUID, the unique ID of the node, e.g. 53532db3-0626-4074-ae50-a87ab1f84538
Parent-UUID, the unique identifier of its parent. In case of first-level nodes, Parent-UUID is the ID of the main Cloud Server
Manual-S, the flag showing if the node is available for user's manual selection.
Product, the acronym of the server type installed on the node e.g. ED stays for Enterprise Desktop, WS for Workstation etc ...
OS, the operating system of the node host
Comment, the long description of the node if provided by the administrator

To see information about a specific node, provide its UUID. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodelist UUID [--extended]

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodelist UUID [--extended]

Listing the parent cloud server(s) from the node

A node can belong to more than one Cloud Server. To see which are the parent servers, on Linux and macOS:

$ sudo /etc/NX/nxserver --serverlist

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --serverlist

Editing node settings from the Cloud Server

On the Cloud Server host, execute the following command and provide the appropriate option to change settings. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit UUID OPTION

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit UUID OPTION

UUID is the UUID of the first-level node.
OPTION is any of the parameters available for the nxserver --nodeadd command except the '--foreign' qualifier.

Most relevant options are:
--host IP|hostname
--port
--client-connection forward|tunnel
--further-auth-required yes|no
--node-name
--allow-visitor-desktop-sharing yes|no
--allow-guest-desktop-sharing yes|no
--allow-guest-create-virtual yes|no
--node-group
--strict-host-key-checking yes|no

The complete list of options is available in the server usage (sudo /etc/NX/nxserver --help).

If you need to edit a non-first level node, specify its parent by --target UUID where UUID is the parent UUID. This applies to all commands. For example, on Cloud Server CS_A you need to edit the node (node_CS_B) of cloud server B (CS_B) which is a node of Cloud Server A:
nxserver --nodeedit UUID_node_CS_B OPTION --target UUID_CS_B

Editing settings of the parent Cloud Server from the node

On the node, execute the following command and provide the appropriate option to change settings.
On Linux and macOS:

$ sudo /etc/NX/nxserver --serveredit UUID OPTION

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --serveredit UUID OPTION

UUID is the UUID of the Cloud Server
Most relevant OPTIONs are:
--node-name NAME
--host IP|HOSTNAME
--port PORT

Stopping and starting the Nodes from the Cloud Server

Stopping any of the nodes means that new sessions will be not started on that node, but current sessions will stay running. Commands (to be run on the Cloud Server) to stop and start the node are, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodestop UUID
$ sudo /etc/NX/nxserver --nodestart UUID

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodestop UUID
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodestart UUID

Removing the Nodes from the Cloud Server

To completely remove a node from the main Cloud Server, use the following command. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodedel UUID

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodedel UUID

Where UUID is the UUID of the node.

In a multilevel infrastructure, it's possible to delete nodes that are not first-level nodes by specifying their parent cloud server with the '--target UUID' option, where UUID is the UUID of the parent Cloud Server.

It's also possible to remove a node just from the list of nodes displayed to user, without removing it from the Cloud Server, by disabling the manual selection for that node. The node with 'manual selection' disabled is no longer listed among the available nodes in the client UI. You then need to assign users to the node by means of 'nxserver --useradd' or 'nxserver --useredit' commands if you want to let users access it.
To disable the manual selection option for the given node, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit UUID --manual-selection no

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  nxserver --nodeedit UUID --manual-selection no

Removing the parent Cloud Server from the Node

On the node, execute the following command. On Linux and macOS:

$ sudo /etc/NX/nxserver --serverdel UUID

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --serverdel UUID

Where UUID is the UUID of parent Cloud Server to which the node belongs. By removing the parent Cloud Server, the node is no longer part of that Cloud Server setup.

3.3. Changing IP/Hostname and Port for the Node^New!

To change the IP or hostname of the node and/or the port to which the Cloud Server connects, use the following commands on the Cloud Server host. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit UUID --host IP|HOSTNAME --port PORT

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit UUID --host IP|HOSTNAME --port PORT

To change the IP or hostname of the Cloud Server and/or the port to which the node connects, use the following commands on the node host. On Linux and macOS:

$ sudo /etc/NX/nxserver --serveredit UUID --host IP|HOSTNAME --port PORT

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --serveredit UUID --host IP|HOSTNAME --port PORT

3.4. Using the SSH Protocol for Cloud Server-to-node Connections

By default communication between Cloud Server and its node uses the NX protocol on port 4000. As an alternative, it's possible to use the SSH protocol which uses by default port 22 or 4022 on Windows. A different protocol and port can be set while adding the node, or later by editing settings. This can be done both when the Cloud Server and the node use the direct connection or the inverse connection.

 
3.5. Forwarding Client Connections to Nodes in the Same Network ('Forward' vs. 'Tunnel')

By default, client connections are tunneled via Cloud Server to the nodes. This is the tunnel connection method which means that the client traffic is relayed through the Cloud Server to the node and with the protocol specified for the Cloud Server-to-node communication. This method allows connecting to nodes behind a NAT or firewall, given that the necessary port is open, also when the Cloud Server is in a DMZ.

If the clients can connect directly to the node, because they are part of the same LAN or VPN, you can set the forward connection method. With this method, the client will try to connect to the node. This requires that the node is reachable by the client.

You can set the forward method while adding the node or by editing it later by using the following commands on the Cloud Server. On Linux or macOS:

$ sudo /etc/NX/nxserver --nodeadd NODEIP --node-name NAME --client-connection forward
$ sudo /etc/NX/nxserver --nodeedit UUID --client-connection forward

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeadd NODEIP --node-name NAME --client-connection forward
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit UUID --nodeadd NODEIP --client-connection forward

The general format of the command to restore the tunnel connection by editing the node is:

nxserver --nodeedit NODEIP --node-name NAME --client-connection tunnel

It's also possible to forward client connections to the node on a specific network interface and port, but only when the client connection is not tunneled. This can be useful when the server host has multiple NICs and you prefer to have a separate network for Cloud Server and client connections.

Specify a different NIC and port for client connections by NX protocol with the following options:

nxserver --nodeadd NODEIP --node-name NAME --forward-nx-host NODE_IP2 --forward-nx-port PORT2

For client connections using the SSH protocol, use instead:

nxserver --nodeadd NODEIP --node-name NAME --forward-ssh-host NODE_IP2 --forward-ssh-port PORT2

It's also possible to specify a network interface and port also later by means of the --nodeedit command and the same parameters above: --forward-nx-host and --forward-nx-port for the NX protocol; --forward-ssh-host and --forward-ssh-port for SSH.

 
3.6. Giving access to the Node only via Cloud Server

The NoMachine server installed on the node accepts connections to its IP, i.e. it's an autonomous server.

It's possible to configure it to work only as a node of the Cloud Server. To do that via the UI, enter the Clouds panel and select the checkbox 'Let this server work only as a node of a cloud server'.

To do that via configuration, be sure to set in the server configuration file of the node host:
EnableDirectConnections 0
(remove the pre-pending # from the key name).

To allow users to connect directly to the server on the node, set:
EnableDirectConnections 1

 3.7. Creating Multiple Levels of Nodes

There are two ways to add nodes to a sub-level Cloud Server:

1. Connect to the sub-level Cloud Server (first method)

   Given that the sub-level Cloud Server is already a node of the main Cloud Server, connect to it via UI to add a node to it or run the 'nxserver --nodeadd' command on its host.

2. Add the node via the main Cloud Server (second method)

   Given that the sub-level Cloud Server is already a node of the main Cloud Server, to add it a node: mouse click on the Cloud Server to open the context menu and choose 'Add node'. This will let you add a new node to it.

   The node can be added to the sub-level Cloud Server also via command line, in this case it's necessary to provide the UUID of the parent Cloud Server ( --target Parent-UUID).

A practical example for building a multi-level infrastructure from command line
Let's assume to have the following three NoMachine server installations:
Cloud Server 1, CS1
Cloud Server 2, CS2
Enterprise Desktop, ED.
CS1 is the main server which will rule the whole infrastructure, we want to add CS2 to CS1 and ED to CS2.

On CS1 execute:
nxserver --nodeadd IP_of_CS2 --node-name "CS2"
Let's retrieve now the UUID of CS2:
nxserver --nodelist --extended
Then we want to add ED under CS2:
nxserver --nodeadd IP_of_ED --target uuid_of_CS2 --node-name  "ED"  

The same server can be a node of more than one Cloud Server. For example, let's say that we have a fourth NoMachine server, Workstation WS, and that we want to add it to both CS1 and CS2:

nxserver --nodeadd IP_of_WS --node-name "WS-CS1"
nxserver --nodeadd IP_of_WS --target uuid_of_CS2 --node-name "WS-CS2"

To edit not-first level nodes, it's necessary to provide their UUID and also the UUID of their parent Cloud Server, e.g.:

nxserver --nodeedit UUID_of_WS --target uuid_of_CS2 OPTION

 
3.8. Adding Unix-based Stations without NoMachine as Nodes

It's possible to add also 'Foreign X Servers' as nodes, which are Unix-like hosts running an unsupported Operating System for which we don't build native packages.

Pre-requisites to integrate a Foreign X Server in the NoMachine hierarchical infrastructure are:
1. A Unix-based operating system is running on the Foreign X Server host, e.g. Solaris X86, HP-UX, AIX, BSD etc ...

2. An X server is up and running on the Foreign X Server host.

3. The X server listens for TCP connections.

This is necessary to let the X server listen to remote connections from clients and enables the X11 forwarding from an external host. Please consult the official documentation of your Linux distribution for instructions and advices.

4. A desktop environment (e.g. GNOME) is installed on the Foreign X Server host.

5. A system account is present for each user who will need to log-in from remote to the Foreign X Server host.

6. The xauth command is installed on the Foreign X Server host.

7. The Foreign X Server has SSH connectivity.

To add the Foreign X Server to the main Cloud Server, on the Cloud Server host execute the following command:

nxserver --nodeadd <Foreign X Server IP or hostname> --foreign --node-name <name>
Further options:
nxserver --nodeadd <Foreign X Server IP or hostname> [ --manual-selection yes | no ]  [ --node-comment <comment>]

3.9. Re-installing NoMachine on a Node

When the NoMachine server is reinstalled on the node (i.e. it has been uninstalled and then installed again), execute the 'nxserver --nodereadd' command on the Cloud Server to update information of a node in the backend of the main server and update automatically the certificate for main server-node authentication. It will add automatically the host key to known_hosts file (if SSH is used) or to client.crt (if NX protocol is used).

On Linux and macOS

$ sudo /etc/NX/nxserver --nodereadd UUID

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodereadd UUID

3.10. Administering the Node Remotely via UI^New!

You can administer the remote NoMachine server installed on the node via User Interface, without the need to be physically on that server host or connected via NoMachine session.

Open the NoMachine client interface on your computer, select the remote server and right mouse click to open the menu. Choose 'Server admin' and login as administrator to that server host when requested:

You will then access the Server Settings panel to administer that server as if you're in front of it.

3.11. Retrieving the Node History

From command line on a terminal on the main Cloud Server, you can also retrieve the history of a remote node. On Linux and macOS execute:

$ sudo /etc/NX/nxserver --history OPTION --target UUID   

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history OPTION --target UUID   

UUID is the UUID of the node

OPTION can be:
--file FILE to save information to the given file
SESSIONID or USERNAME to retrieve information for the given session or user
--client-type and/or --client-version and/or --client-platform to display information about the clients
--stats to elaborate statistics data about sessions
--clear to clear history
--verbose to display additional information

4. Configure Users Access

With the Cloud Server it's possible assign users and groups of users to a specific node or nodes, as well as create profile rules for each of them. It's also possible to configure user access on the Cloud Server and its associated nodes in multiple ways: system account, guest or visitor.

 4.1. Assigning Users to the First Available NoMachine Enterprise Desktop

This feature applies only to a multi-server setup made of a Cloud Server + a pool of Enterprise Desktop nodes. When the Enteprise Desktop nodes are organized in one or more groups, the Cloud Server can be configured to assign the first available desktop to the incoming user. This assumes that each user logs-in with a different account.

When the automatic assignment of the Enterprise Desktop is enabled, the algorithm firstly checks if the connecting user is already logged-in to a desktop. In this case, that Enterprise Desktop is chosen. I.e. by default, if the user is already logged to an Enterprise Desktop, he/she will be reassigned to the same host.

If not, it looks for the first available desktop in the group, the desktop is considered available when it's in login window mode and nobody is logged-in to.

If there is not an available desktop, a message informs the user that all the desktops are already in use.

To enable the automatic assignment of the Enterprise Desktop, on the Cloud Server host execute the following.

Step 1- Create one or more groups of nodes and enable the automatic selection of the desktop for that group, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodegroupadd NODEGROUPNAME --auto-desktop-selection yes

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodegroupadd NODEGROUPNAME --auto-desktop-selection yes

To exclude an Enterprise Desktop when one user is already logged-in by NoMachine, regardless if the incoming user has the same account or not, use the '--independent-connections yes' option in conjunction with '--auto-desktop-selection yes, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodegroupadd GROUP_of_EDS --auto-desktop-selection yes --independent-connections yes
or: 
$ sudo /etc/NX/nxserver --nodegroupedit GROUP_of_EDS --auto-desktop-selection yes --independent-connections yes

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodegroupadd GROUP_of_EDS --auto-desktop-selection yes --independent-connections yes
or: 
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --nodegroupedit GROUP_of_EDS --auto-desktop-selection yes --independent-connections yes

Step 2- Then add the node to the Cloud Server, you can specify there furhter parameters among those supported by the 'nxserver --nodeadd' command. On Linux and macOS:

$ sudo /etc/NX/nxserver --nodeadd IP_of_ED

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeadd IP_of_ED

Step 3- Finally, add the node to the server group previously created, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit IP_of_ED --node-group NODEGROUPNAME

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit IP_of_ED --node-group NODEGROUPNAME

You can add the node to the node group at any moment by means of the 'nxserver --nodeedit' command. To remove it from the group, use 'nxserver --nodedel UUID --node-group NODEGROUPNAME'

 4.2. Forwarding Users or Groups of Users to a Specific Node

In the default configuration, all the available nodes are listed to users, which will then be able to choose any of them. If the 'manual selection' is disabled for a node, this node will be not listed to users. In this case, users will be able to connect to this node only if they have been explicitly redirected or assigned.

Assigning the user to a node is not mandatory but if this is set, the user's connection will be transparently routed to the specific node, even if it doesn't have the manual selection disabled.

User's assignment can be modified, set and unset at any moment.

To assign a given user to a specific node, do the following.

Step 1- Add the node to the Cloud Server, you can specify any of the available parameters, on Linux and macOS:

$ sudo /etc/NX/nxserver --nodeadd NODEIP

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeadd NODEIP

Step 2- Then assign the user to the node (the user must already have a valid account on the Cloud Server and on the node). On Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --forward-connection UUID

Where UUID is the UUID of the node as it appears in the output of the 'nxserver --nodelist --extended' command.

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --forward-connection UUID

It's also possible to assign a given group of users to a specific node. The group of users can be a system group or a NoMachine group of users.

To forward a system group or an existing NoMachine group to the node, specified by its UUID, use on Linux and macOS:

$ sudo /etc/NX/nxserver --groupedit GROUPNAME --forward-connection UUID

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --groupedit GROUPNAME --forward-connection UUID

To create a NoMachine group of users on Linux and macOS:

$ sudo /etc/NX/nxserver --groupadd GROUPNAME

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --groupadd GROUPNAME

You can create the NoMachine group of users and forward it to a given node by means of a unique command: 'nxserver --groupadd GROUPNAME --forward-connection UUID'.

Listing the 'Forward connection' directives

The forwarding directive is displayed as output of the 'nxserver --userlist' command in the 'Forwarded to' column. Provide USERNAME if you want to display information about a specific user only. On Linux and macOS:

$ sudo /etc/NX/nxserver --userlist [USERNAME]

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userlist [USERNAME]

Removing the 'Forward Connection' directives

To remove directive set for a given user on Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --forward-connection none

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --forward-connection none

To remove directive for a system group or a NoMachine group of users, on Linux and macOS:

$ sudo /etc/NX/nxserver --groupedit GROUPNAME --forward-connection none

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --groupedit GROUPNAME --forward-connection none

4.3. Assigning Users or Groups of Users to Specific Nodes

$ sudo /etc/NX/nxserver --ruleadd --class node --type UUID --value no|yes OPTIONS

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type UUID --value no|yes OPTIONS

$ sudo /etc/NX/nxserver --nodelist --extended

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodelist --extended

$ sudo /etc/nxserver --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value no --user nxtest01
$ sudo /etc/nxserver --ruleadd --class node --type ED2:4000 --value no --user nxtest01

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value no --user nxtest01d
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type ED2:4000 --value no --user nxtest01

$ sudo /etc/NX/nxserver --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value no
$ sudo /etc/NX/nxserver --ruleadd --class node --type ED2:4000 --value no
$ sudo /etc/NX/nxserver --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value yes --group nxgroup01
$ sudo /etc/NX/nxserver --ruleadd --class node --type ED2:4000 --value yes --group nxgroup01

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value no
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --ruleadd --class node --type ED2:4000 --value no
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type 7596bc90-f81c-483e-9d91-4571dc582596 --value yes --group nxgroup01
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class node --type ED2:4000 --value yes --group nxgroup01

$ sudo /etc/NX/nxserver --ruledel --user USERNAME

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruledel --user USERNAME

$ sudo /etc/NX/nxserver --ruledel --group GROUPNAME

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruledel --group GROUPNAME

$ sudo /etc/NX/nxserver --nodeedit UUID --further-auth-required yes
$ sudo /etc/NX/nxserver --nodeedit UUID --further-auth-required no

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit UUID --further-auth-required yes
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeedit UUID --further-auth-required no

 4.5. Setting Profiles for the Nodes (Rules Propagation)

It's possible to create any of the available profile rules on the Cloud Server host and propagate it to all nodes, to a given one or to groups of nodes.

Profile rules will be applied also to nodes running a NoMachine server which doesn't support profiles (e.g. the Workstation).

Profile rules are grouped in classes: 'session', 'service', 'feature' and 'node'.
Each class includes a number of 'types' of rules.
Each type of rule can be yes or no or set to a value.

To create profiles for the nodes on the Cloud Server, always specify 'propagation' as class and provide the appropriate type of rule with the --type option and value with the --value parameter.

Some practical examples

To completely disable file transfer on the Cloud Server and on all nodes, use on Linux and macOS:

$ sudo /etc/NX/nxserver --ruleadd --class propagation --type server-file-transfer --value no
$ sudo /etc/NX/nxserver --ruleadd --class propagation --type client-file-transfer --value no

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class propagation --type server-file-transfer --value no
>  %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class propagation --type client-file-transfer --value no

To completely disable copy&paste on a group of nodes, on Linux and macOS:

$ sudo /etc/NX/nxserver --ruleadd --class propagation --type server-clipboard --value no --node-group NODEGROUPNAME
$ sudo /etc/NX/nxserver --ruleadd --class propagation --type client-clipboard --value no --node-group NODEGROUPNAME

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class propagation --type server-clipboard --value no --node-group NODEGROUPNAME
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --ruleadd --class propagation --type client-clipboard --value no --node-group NODEGROUPNAME

To forbid audio on a specific node (identified by its UUID) and for a specific user, on Linux and macOS:

$ sudo /etc/NX/nxserver --ruleadd --class propagation --type audio --value no --node UUID --user USERNAME

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --ruleadd --class propagation --type audio --value no --node UUID --user USERNAME

Profiles are available for the following types of rules:

 4.6. Connect Without an Account (Guest Desktop Sharing Users and Visitors)^New!

Guest Desktop Sharing is mainly conceived for temporary and on-the-fly connections to the remote desktop of cloud server's nodes, for example for remote assistance or for participating to a shared lesson on the desktop. It cannot be used in the case of unattended desktops because the deskop owner's approval is always mandatory.

Guest Desktop Sharing Users or simply 'Guests'
With Guest Desktop Sharing, users are able to connect to the remote desktop of a node without the need to have a valid account on that host. The desktop owner must grant access by authorising the guest's connection request (Physical Guest Desktop Sharing). Guest Desktop Sharing is available also when the node works as a standalone server and accepts connections not only through a Cloud Server.

If the node is Linux and a NoMachine terminal server product is installed - like Workstation, Small Business Terminal Server, Terminal Server, Enterprise Terminal Server and Enterprise Terminal Server Cluster - the guest desktop sharing is available also for connections to NoMachine Linux virtual desktops (Virtual Guest Desktop Sharing).

If you login as guest to the Cloud Server, you will login as guest also on the nodes with Guest Desktop Sharing enabled. A guest on the Cloud Server cannot become a system user on the nodes.

IMPORTANT
Users who login as guests to the Cloud Server cannot connect to the physical desktop of the Cloud Server.

Visitors (available only for cloud servers)
A user who logged to the cloud server with a system account can become a Visitor on the node if Guest Desktop Sharing is enabled on that node: he/she will be prompted with the possibility to login with system credentials (if he/she has an account on that node) or as a guest.

A Visitor works exactly as a Guest Desktop Sharing user, he/she doesn't need a system account on the node and can connect only if the remote desktop owner accepts that, but what's important to notice is that:

i) Visitors are known users, since they are already logged to the cloud server, while Guest Desktop Sharing users are anonymous.

ii) With Visitors, users can login to the nodes even when login as guest is disabled, e.g. for security policies.

If you login as system user to the Cloud Server, you cannot login as (anonymous) guest on the nodes, but you can login as a Visitor. The desktop owner will then know your username.

How to enable physical and virtual Guest Desktop Sharing to the nodes via UI

First step - Open the Settings -> Server -> Security panel on the Cloud Server or connect there via client and use the remote server administration UI.

In the 'Server security' panel, check the 'Allow guest desktop sharing access through this server' option.

Second step - In the menu of settings for the server, open Nodes and select the node where you want to enable Guest Desktop Sharing and click on 'Edit node'.

In the 'Edit node' panel, check the 'Allow guest access to this node through the cloud server' option.

When Guest Desktop Sharing access is enabled, it applies to both physical Guest Desktop Sharing access and virtual Guest Desktop Sharing access (if the nodes are Linux and support NoMachine virtual desktops).

How to enable physical and virtual Guest Desktop Sharing to the nodes via command line

First step - On the Cloud Server host, edit server.cfg and ensure to have 'guest' listed among the values of the PhysicalDesktopAccessNodes key. Such key defines which kind of user is allowed to connect to the nodes.
For example:
PhysicalDesktopAccessNodes administrator,trusted,system,owner, guest

If the nodes are running a Linux terminal server like NoMachine Workstation, Small Business Terminal Server, Terminal Server, Enterprise Terminal Server or Enterprise Terminal Server Cluster, it's also possible to enable Guest Desktop Sharing access to NoMachine virtual desktops.
Edit the server.cfg file on the Cloud Server and ensure that 'guest' is listed in this key:
VirtualDesktopAccessNodes administrator,trusted,system,owner,guest
(Remove the pre-pending # from the key name).

Second step - Edit the node from the Cloud Server host and enable guest desktop sharing, by executing the appropriate command.
On Linux and macOS, to allow Guest Desktop Sharing:

$ sudo /etc/NX/nxserver --nodeedit NODE --allow-guest-desktop-sharing yes 

NODE can be specified by its uuid or IP or hostname or name.

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --nodeedit NODE --allow-guest-desktop-sharing yes 

Set commands above to 'no' (--allow-guest-desktop-sharing no) if you want to disable Guest Desktop Sharing access on that node.

When Guest Desktop Sharing access is enabled, it applies to both physical Guest Desktop Sharing access and virtual Guest Desktop Sharing access (if the nodes are Linux and support NoMachine virtual desktops).

Access by Guests always require approval of the desktop owner. The other type of users can access with or without the need of been authorized depending on how the PhysicalDesktopAccessNoAcceptance key is configured on the node.

How to enable Visitors for physical and virtual Guest Desktop Sharing to the nodes via UI

First step - Open the Settings -> Server -> Security panel on the Cloud Server or connect there via client and use the remote server administration UI.

In the 'Security' panel, check the 'Allow visitor desktop sharing through this server' option.

Second step - In the menu of settings for the server, open Nodes and select the node where you want to enable Visitors' access and click on 'Edit node'.

In the 'Edit node' panel, check the 'Allow visitor access to this node through the cloud server' option.

How to enable Visitors for physical and virtual Guest Desktop Sharing to the nodes via command line

First step - On the Cloud Server host, edit server.cfg and ensure to have 'visitor' listed among the values of the PhysicalDesktopAccessNodes key.
For example:
PhysicalDesktopAccessNodes administrator,trusted,system,owner, visitor

If the nodes are running a Linux terminal server like NoMachine Workstation, Small Business Terminal Server, Terminal Server, Enterprise Terminal Server or Enterprise Terminal Server Cluster, it's also possible to enable Guest Desktop Sharing access to NoMachine virtual desktops.
Edit the server.cfg file on the Cloud Server and ensure that 'visitor' is listed in this key:
VirtualDesktopAccessNodes administrator,trusted,system,owner,visitor
(Remove the pre-pending # from the key name).

Second step - Edit the node on the Cloud Server and enable Guest Desktop Sharing for Visitors.

On Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit NODE --allow-visitor-desktop-sharing yes 

NODE can be specified by its uuid or IP or hostname or name.

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --nodeedit NODE --allow-visitor-desktop-sharing yes 

Set commands above to 'no' if you want to disable Visitors' access.

When Guest Desktop Sharing access for Visitors is enabled, it applies to both physical Guest Desktop Sharing access and virtual Guest Desktop Sharing access (if the nodes are Linux and support NoMachine virtual desktops).

Key PhysicalDesktopAccessNodes on the Cloud Server can contain both 'guest' and 'visitor'.

Access by Visitors always require approval of the desktop owner. The other type of users can access with or without the need of been authorized depending on how the PhysicalDesktopAccessNoAcceptance key is configured on the node.

 4.7. Using System Guest Users Accounts (Virtual Desktop Guests) on Linux Nodes

Virtual Desktop Guests are local system accounts generated automatically on demand. They can create new virtual desktops. For connections to the physical desktop, use the Guest Desktop Sharing Users.

Virtual Desktop Guests are available only for nodes running NoMachine Terminal Server, Enterprise Terminal Server or Enterprise Terminal Server Cluster for Linux. This feature is not enabled by default and must be activated on each node. A number of configuration keys in the server.cfg file on the node allow to determine the behaviour of these guest accounts, e.g. how many virtual desktops they can run before the account is terminated, for how long the guest account is kept alive before being deleted and so on.

How to enable Virtual Desktop Guests users via UI

First step - Open the Settings -> Server -> Security panel on the Cloud Server or connect there via client and use the remote server administration UI.

In the 'Security' panel, check the 'Allow visitor desktop sharing through this server' option.

Second step - In the menu of settings for the server, open Nodes and select the node where you want to enable guest access and click on 'Edit node'.

In the 'Edit node' panel, check the 'Allow guest users to create new virtual desktops' option.

How to enable Virtual Desktop Guests via command line

First step - On the Cloud Server host, edit server.cfg and ensure to have 'guest' listed among the values of the PhysicalDesktopAccessNodes key.
For example:
PhysicalDesktopAccessNodes administrator,trusted,system,owner, guest

Second step - Edit the node on the Cloud Server and enable Virtual Desktop Guests.

On Linux and macOS:

$ sudo /etc/NX/nxserver --nodeedit NODE --allow-guest-create-virtual yes

NODE can be specified by its uuid or IP or hostname or name.

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --nodeedit NODE --allow-guest-create-virtual yes

Virtual Desktop Guests don't know their username and password and cannot therefore unlock the remote screen if screen locking is enabled. It's therefore necessary to disable it on the system.

They cannot connect to the remote desktop (physical or virtual) without the authorization of the desktop owner.

Access by Guests always require approval of the desktop owner. The other type of users can access with or without the need of been authorized depending on how the PhysicalDesktopAccessNoAcceptance key is configured on the node.

 5. Set-up a Failover Cluster for High Available Access

A NoMachine failover cluster is a group of two Enterprise Cloud Server Cluster that work together to maintain high available access to the centralized infrastructure. This is an active/passive cluster where the primary server is at the beginning active and ready to accept users' connections, while the secondary server is passive, its task is to constantly monitor the primary server.

When the secondary server loses contact with the primary server, the cluster failover occurs: the secondary server takes place of the primary server to grant the continuity of services. Sessions running on the remote nodes continue to stay connected, management of server-node connections is passed from the primary to the secondary server, the virtual IP of the cluster is taken by the secondary server, an ARP notification is sent to local network devices to update their ARP cache entries (Ethernet MAC to IP address link associations).

Some remarks:

If the ECSC has already a number of nodes and you want to set it in a failover cluster, just create the cluster. The multi-server environment doesn't need further configurations. Please note that when the failover cluster is set, the uuid of the main ECSC will be different. Additionally, users will then have to connect to the shared IP of the cluster server, not to the IP of the main ECSC as before.
Once the failover cluster is created, to add nodes in 'inverse mode' (from node to Cloud Server), connect to the active Cloud Server by using the shared IP of the cluster. Note that nodes added in inverse mode before the creation of the failover cluster, will be not configured in the cluster. Remove and re-add them.

If nodes added in 'inverse mode' need to use the SSH protocol, be sure that the failover cluster has the SSH protocol set by specifying it while creating the cluster.

If the ECSC is instead a node, it's necessary to remove it from the multi-host environment before setting it in a failover cluster. Then create the failover cluster. Finally add it again to its parent Cloud Server by specifying the shared IP of the failover cluster, not the IP of the single Enterprise Cloud Server Cluster.
It's important that custom keys in server.cfg and node.cfg are set to the same value both on the primary and on the secondary server. For example if 'NXGSSAPIStrictAcceptorCheck 0' is set on the primary server in server.cfg, it must be set to the same value also on the secondary server.

 5.1. Configuring the Failover Cluster on Linux

STEP 1: Identify which Enterprise Cloud Server Cluster host will be the primary server (ECSC1) and which will be the secondary server (ECSC2).

STEP 2: Configure the multinode setup for ECSC1, i.e. ensure that all the required servers subsystems have been already added to this Cloud Server.

STEP 3: Set-up the 'primary server' role to ECSC1.

On ECSC1, execute the ifconfig command and check the local IP address and interface that is assigned to, for example:

$ /sbin/ifconfig 
eth0      Link encap:Ethernet  HWaddr 08:00:27:7C:30:73  
          inet addr:192.168.0.87  Bcast:192.168.0.255  Mask:255.255.255.0

If interface is eth0 then execute:

$ sudo /etc/NX/nxserver --clusteradd --local  IP_of_ECSC1  --shared IP_of_the_cluster_host

If interface is different, execute the command with the --interface option:

$ sudo /etc/NX/nxserver --clusteradd   --local  IP_of_ECSC1  --shared  IP_of_the_cluster_host  --interface  interface_of_ECSC1:0 

IP_of_the_cluster_host must be a free IP, that will be assigned by NoMachine as a shared IP to the failover cluster. When users connect to the Cloud Server, they must use that shared IP.

Optionally you may specify the following parameters to the 'nxserver --clusteradd' command:

If nodes added in 'inverse mode' need to use the SSH protocol, ensure to enable it for the cluster by adding the --proto option to the command above: --proto NX:4000,SSH:22

STEP 4: Set-up the 'secondary server' role to ECSC2

On ECSC2, execute the ifconfig command and check the local IP address and interface that is assigned to.

On ECSC1 execute:

$ sudo /etc/NX/nxserver --clusteradd   IP_of_ECSC2

If interface on ECSC2 is different than eth0, execute the clusteradd command with the --interface option:

 $ sudo /etc/NX/nxserver --clusteradd    IP_of_ECSC2   --interface  interface_of_ECSC2:0 

If the operating system of the primary server and of the secondary server are different (e.g. Linux and Windows), be sure to specify the --interface option when adding the secondary server to the cluster.

STEP 5: Restart ECSC1 and ECSC2

Firstly on ECSC1, then on ECSC2 execute:

$ sudo /etc/NX/nxserver --restart

It's mandatory to restart both the primary and the secondary server.

5.2. Configuring the Failover Cluster on MacOS

STEP 1: Identify which Enterprise Cloud Server Cluster host will be the primary server (ECSC1) and which will be the secondary server (ECSC2).

STEP 2: Configure the multinode setup for ECSC1, i.e. ensure that all the required servers subsystems have been already added to this Cloud Server.

STEP 3: Set-up the 'primary server' role to ECSC1.

On ECSC1 execute the ifconfig command and check local IP address and interface that is is assigned to, for example:

$ ifconfig
en0:  (...)
        inet 10.0.1.28 netmask 0xffff0000 broadcast 10.0.255.255

If interface is en0 then execute:

$ sudo /etc/NX/nxserver --clusteradd    IP_of_ECSC1  --shared  IP_of_the_cluster_host

If interface is different, execute the command with the --interface option:

$ sudo /etc/NX/nxserver --clusteradd  IP_of_ECSC1 --shared  IP_of_the_cluster_host  --interface  interface_of_ECSC1 

IP_of_the_cluster_host must be a free IP, that will be assigned by NoMachine as a shared IP to the failover cluster. When users connect to the Cloud Server, they must use that shared IP.

Optionally you may specify the following parameters to the 'nxserver --clusteradd' command:

If nodes added in 'inverse mode' need to use the SSH protocol, ensure to enable it for the cluster by adding the --proto option to the command above: --proto NX:4000,SSH:22

STEP 4: Set-up the 'secondary server' role to ECSC2

On ECSC2 execute the ifconfig command and check local IP address and interface that is is assigned to.

On ECSC1 execute:

$ sudo /etc/NX/nxserver --clusteradd    IP_of_ECSC2

If interface on ECSC2 is different than en0, execute the clusteradd command with the --interface option:

 $ sudo /etc/NX/nxserver --clusteradd     IP_of_ECSC2   --interface  interface_of ECSC2

If the operating system of the primary server and of the secondary server are different (e.g. macOS and Linux), be sure to specify the --interface option when adding the secondary server to the cluster.

STEP 5: Restart ECSC1 and ECSC2

Firstly on ECSC1, then on ECSC2 execute:

$ sudo /etc/NX/nxserver --restart

It's mandatory to restart both the primary and the secondary server.

5.3. Configuring the Failover Cluster on Windows

STEP 1: Identify which Enterprise Cloud Server Cluster host will be the primary server (ECSC1) and which will be the secondary server (ECSC2).

STEP 2: Configure the multinode setup for ECSC1, i.e. ensure that all the required servers subsystems have been already added to this Cloud Server.

STEP 3: Set-up the 'primary server' role to ECSC1.

Execute the following operations on ECSC1 in a CMD console opened as administrator.

Execute the ipconfig command and check local IP address and interface that is is assigned to, for example:

> ipconfig
Windows IP Configuration

Ethernet adapter Ethernet:
  (...)
   IPv4 Address. . . . . . . . . . . : 10.0.1.11

Then, on Windows 10 and 11, if IP address is obtained with DHCP service, execute:

>netsh interface ipv4 set interface interface="interface name" dhcpstaticipcoexistence=enabled

For example:

>netsh interface ipv4 set interface interface="Ethernet" dhcpstaticipcoexistence=enabled

On Windows 7 and 8, there is not the possibility to add a static IP to network interface via DHCP service. You therefore need to set the static IP. Do that before proceeding with the procedure below.

Finally, if interface is Ethernet, execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteradd  IP_of_ECSC1  --shared  IP_of_the_cluster_host

Otherwise execute the command with the --interface option:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --clusteradd  IP_of_ECS1 --shared  IP_of_the_cluster host  --interface   interface_of_ECS1

IP_of_the_cluster_host must be a free IP, that will be assigned by NoMachine as a shared IP to the failover cluster. When users connect to the Cloud Server, they must use that shared IP.

Optionally you may specify the following parameters to the 'nxserver --clusteradd' command:

If nodes added in 'inverse mode' need to use the SSH protocol, ensure to enable it for the cluster by adding the --proto option to the command above: --proto NX:4000,SSH:22

STEP 4: Set-up the 'secondary server' role to ECSC2

On ECS2 execute the ipconfig command and check local IP address and interface that is is assigned to.

On ECSC1 execute:

>nxserver --clusteradd   IP_of_ECS2

If interface on ECSC2 is different than Ethernet, execute the clusteradd command with the --interface option:

>nxserver --clusteradd   IP_of_ECS2 --interface   interface_of_ECS2

If the operating system of the primary server and of the secondary server are different (e.g. Linux and Windows), be sure to specify the --interface option when adding the secondary server to the cluster.

STEP 5: Restart ECSC1 and ECSC2

Firstly on ECSC1, then on ECSC2 execute:

> nxserver --restart

It's mandatory to restart both the primary and the secondary server.

 5.4. Tuning the Failover Cluster Parameters

Default settings apply to the most common cases. It may be necessary, however, to tune some parameters to fit some specific business requirements or network conditions. These are the default settings which define the cluster's heartbeat and rule health detection between the two NoMachine servers in the cluster.

The global failover time depends on:

global failover time = grace period + timeout + router's convergence time

 5.5. Administering the Failover Cluster

Replacing the RSA key pair for the Failover Cluster (optional)

The two Enterprise Cloud Server Cluster in cluster use a RSA key pair to connect and synchronize information between their databases. This key pair is valid only for the nx user, a special system account created during the installation of the NoMachine server software and reserved for internal operations.

You may replace the default RSA key-pair provided with the installation by generating your own key-pair. See the guide about how to use different keys or certificates with NoMachine in the https://www.nomachine.com/all-documents for detailed instructions.

Once replaced, remember to update the cluster configuration. Run on one of the two Enterprise Cloud Server Cluster the following command to propagate configurations to the other server in the cluster. On Linux and macOS:

$ sudo /etc/NX/nxserver --clusteredit

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

Changing network interface and/or subnet mask

On Linux and macOS:

$ sudo /etc/NX/nxserver --clusteredit <Enterprise Cloud Server Cluster IP> --interface <interface> --netmask <mask>

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit <Enterprise Cloud Server Cluster IP> --interface <interface> --netmask <mask>

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

Changing IP of localhost, primary server and/or failover cluster

On Linux and macOS:

$ sudo /etc/NX/nxserver --clusteredit --local <server IP> --master <server IP> --shared <server IP>

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit --local <server IP> --master <server IP> --shared <server IP>

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

Changing Failover Cluster parameters (heartbeats)

On Linux and macOS:

$ sudo /etc/NX/nxserver --clusteredit --grace <time> --retry <number> --probe <time> --interval <number> --timeout <number>

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit --grace <time> --retry <number> --probe <time> --interval <number> --timeout <number>

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

Removing an Enterprise Cloud Server from the Failover Cluster

On Linux and macOS:

$ sudo /etc/NX/nxserver --clusterdel SERVER_IP

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusterdel SERVER_IP

Adding a new node to the primary server and updating the Failover Cluster accordingly

Execute on the primary server, Linux or macOS:

$ sudo /etc/NX/nxserver --nodeadd NODEIP
$ sudo /etc/NX/nxserver --clusteredit

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodeadd NODEIP
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

Removing a node from the primary server and updating the Failover Cluster accordingly

Execute on the primary server, Linux or macOS:

$ sudo /etc/NX/nxserver --nodedel UUID
$ sudo /etc/NX/nxserver --clusteredit

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodedel UUID
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --clusteredit

Versions previous than v8.2 were using instead command 'nxserver --clusterupdate'.

 5.6. A Practical Example

A practical example
Target is to set-up the failover cluster between 2 Enterprise Cloud Server Cluster hosts, Cloud1 and Cloud2. This example assumes that they are both Linux hosts.

1. Install Enterprise Cloud Server Cluster on Cloud1.

2. Add the nodes to Cloud1 via:

nxserver --nodeadd NODEIP
NODEIP is the IP or hostname of the node to be added to the Cloud Server. For example:
$ sudo /etc/NX/nxserver --nodeadd 172.17.10.12

3. Install your second Enterprise Cloud Server Cluster on Cloud2.

4. Assign to Cloud1 the active role (execute the command on Cloud1)

nxserver --clusteradd --local <ip of Cloud1> --shared <virtual IP to be shared across both Cloud Servers> --netmask <netmask, only needed if different than 255.255.255.0>
For example:
$ sudo /etc/NX/nxserver --clusteradd --local 172.17.10.10 --shared 172.17.10.100 --netmask 255.255.0.0

5. Associate the second Enterprise Cloud Server to the cluster with the following command (execute the command on Cloud1):

nxserver --clusteradd <IP of second Cloud Server, Cloud2> --netmask <netmask, only needed if different than 255.255.255.0>
For example:
$ sudo /etc/NX/nxserver --clusteradd 172.17.10.11 --netmask 255.255.0.0

6. Restart nxserver on Cloud1:

nxserver --restart

7. Restart nxserver on Cloud2:

nxserver --restart

8. Connect via NoMachine client or browser to virtual IP (172.17.10.100)

Finally, you can then verify that high-availability works as expected.

9. Kill Cloud1, i.e. shutdown the host of the active cluster server or shutdown NoMachine server on that active cluster host. The user connected to Cloud1 will be disconnected and immediately reconnected as soon as the secondary cluster server takes the role of active server. This applies only to sessions running on the nodes, if a session was connected to Cloud1, it is terminated.

 6. Initiate a NoMachine Connection (end-user's side)

This section will illustrate what users need to do on their device to connect to the server. Install the NoMachine client application or use the browser to access the remote desktop deployed via cloud server.

 6.1. Connecting by NoMachine Client

Install the free NoMachine Enterprise Client on your device. This is a pure client, without the server side components.

You can also use the free version of NoMachine or whichever other server type, they all provide the client UI for connecting to remote computers.

In the 'Machines' panel you can create a new connection by clicking on 'Add': just provide the IP address of the Cloud Server you want to connect to and port number.

Note that IPv6 is supported: specify the IP address of the server host in IPv6 format (e.g. 2001:0:5ef5:79fb:30c6:1516:3ca1:5695) if you want to use it instead of IPv4.

See also the NoMachine Enterprise Client - Installation and Configuration Guide, section 'Installation' at: https://www.nomachine.com/all-documents

If you're connecting to a NoMachine server which supports web sessions, you can create web-based sessions in the same way as a traditional connection, just select HTTPS as the protocol to be used in the client UI. For more details, please read here: https://www.nomachine.com/getting-started-with-web-based-access-using-nomachine-player

6.2. Connecting by Browsers (Web Sessions)

Once installation is complete, your Cloud Server is ready to go.

Point the browser on your device to:

https://SERVER:4443

Where SERVER is either the name or IP address of the Cloud Server host you want to reach.

E.g., if Cloud Server is installed on a host named 'myserver.com', the URL will look like this:

https://myserver.com:4443

In the login form provide username and password of a valid account on the Cloud Server host and connect.

Depending on how the Cloud Server is configured, you will:
ii) access the list of all nodes with the possibility to choose any of them (default) or:
ii) be re-directed to a specific node.

If you choose to save connection settings, they will be stored in the backend of the NoMachine server for that session and it will be possible to reuse them. The web URL will report the session id (sid), for example:
https://10.45.19.1:4443/?sid=4947a39bb29c5ea531c84951266ebb7e
Just copy it in a link on your desktop and click on it to connect. Note that if the NoMachine server is uninstalled and re-installed, such URL will be no longer valid.

6.3. Preventing Users from Storing their Credentials

To prevent NoMachine client users from storing their credentials, use the EnableClientCredentialsStoring key in the server configuration file. The accepted values are:
player Only users connected via NoMachine client are enabled to save username and password in the connection file stored on their devices (computer, tablet etc ...)
webplayer Only users connected via browser can choose to save their access credentials. They are stored in the browser's cookie, given that the user's browser has cookies enabled.
both All users, regardless if connected via NoMachine client or via web, can store their credentials.
none Users cannot save their username and password. They will be requested to provide their log-in credentials at each connection.

For example, to allow only users connecting via NoMachine client to store credentials, set in the server configuration file:
EnableClientCredentialsStoring player

 7. Configure the Web Player

Browser-based sessions can be configured further by enabling WebRTC and the built-in Apache web server according to your needs. It's also possible to use an alternative Apache server if you prefer.

 7.1. Enabling WebRTC for Audio Support and Multimedia Optimization

The implementation of WebRTC support in browser-based remote desktop sessions has inititally been released as beta and must be enabled explicitly by the administrator by editing the server.cfg file.

With the help of a STUN/TURN server for negotiating NAT traversal, peer-to-peer WebRTC communication can be established also when the web session has to be run behind a NAT.

STEP 1: Uncomment and set the AcceptedWebMethods key as follows to enable the use of WebRTC:

AcceptedWebMethods webrtc

STEP 2: If the node machine where the web session will be started is behind a NAT, you need to uncomment the following section in server.cfg:

Section "STUN"

Host hostname
Port portnumber
User username
Password password

EndSection

and provide relevant information to contact a STUN or TURN server. In this last case change Section name to "TURN".

See also: https://www.nomachine.com/AR07N00892 for further intructions about the configuration and: https://www.nomachine.com/AR07N00894 for an example about how to set up your own STUN/TURN server and configure the Cloud Server accordingly.

 7.2. Configuring Web Sessions

The configuration file for the web player program ('nxwebplayer',which provides the graphical front-end) and the web client program ('nxwebrunner', which manages web sessions) is server.cfg:
/usr/NX/etc/server.cfg on Linux
C:\Program files\NoMachine\etc\server.cfg for 64bit packages on 64bit systems and C:\Program files (x86)\NoMachine\etc\server.cfg for 32bit packages on Windows 64bit systems
/Applications/NoMachine.app/Contents/Frameworks/etc/server.cfg on macOS.

Default settings
The Section directive defines settings for the NoMachine server(s) where the web player application will connect. This directive, by default, points to localhost and looks like:

Section "Server"

Name "Connection to localhost"
Host localhost
Protocol NX
Port 4000
Authentication password

EndSection

Name is a label that can be displayed as an alternative to show hostname of the server.
Host is IP or hostname of the NoMachine server host.
Protocol and Port indicates protocol and port that web player will use to connect to the NoMachine server.
Authentication defines the authentication method to be used when connecting by the web: 'password' for password-based authentication (default) or 'private-key' for key-based authentication.

Changing protocol and port
By default when users connect via web, they will use the NX protocol on port 4000. Supported protocols are NX and SSH with system login

To use the NX protocol (this is the default), set:
Protocol NX
Port 4000

To use SSH protocol and system login, set for Linux and Mac:
Protocol system
Port 22

and for Windows:
Protocol system
Port 4022

Define the authentication method
When connecting via web 8 (since version 6.6.8), it's now possible to use password-based authentication or key-based authentication (available at the moment only for the NX protocol).

To use password-based authentication (this is the default), set:

Authentication password

To use SSH key-based authentication, set:
Protocol NX

Authentication private-key

NoMachine uses by default port 22 for SSH protocol on Linux and Mac, and port 4022 on Windows. The default port for NX protocol is 4000. In order to change the port for NX protocol, change the port for the nxd service and restart it. See the paragraph 'Connecting by NX Protocol'. To change the port for connections by SSH to Linux and Mac hosts it's necessary to modify the listen port for the SSH server on the system. On Windows instead, change the port for the nxsshd service.

Showing hostname or a custom label
To display hostname or IP of the Cloud Server host when connecting by the web, set the following key. This is the default:

EnableWebConnectionName 0

To display the label set in the 'Name' field of Section "Server" set:

EnableWebConnectionName 1

Hiding the tutorial wizard at web session startup
To not display the tutorial wizard for the menu panel at session startup, set:

EnableWebMenuTutorial 0

and to show it (this is the default):

EnableWebMenuTutorial 1

Allowing to log-in as a guest
When the Cloud Server has support for guests enabled, set the following key in server.cfg if you want to let users connect by web as guest users:

EnableWebGuest 1
When this key is enabled, users will have the possibility to choose in the web UI whether to log-in with their credentials or as a guest.

 7.3. Managing the Built-in Apache Web Server (nxhtd)

You can start and stop the NoMachine HTTP server (nxhtd) from the UI: Settings -> Server -> Ports panel. Select the service and click on 'Configure' button. From the NoMachine UI you can also change the port where the web server will be listening (by default 4443 for secure connections).

From command line instead it's possible to do the following.

Stop, start or restart nxhtd

On Linux and macOS:

$ sudo /etc/NX/nxserver --stop nxhtd
$ sudo /etc/NX/nxserver --start nxhtd
$ sudo /etc/NX/nxserver --restart nxhtd

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop nxhtd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --start nxhtd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --restart nxhtd

Automatic restart of the nxhtd service
Each service is automatically restarted at the next boot. You can change the default behavior for the nxhtd service by setting 'manual' or 'automatic': 'nxserver --startmode nxhtd manual' or 'nxserver --startmode nxhtd automatic'.

The nxserver --startmode command operates on the StartHTTPDaemon server configuration key:

StartHTTPDaemon Automatic

and:

StartHTTPDaemon Manual

Disabling the starting of nxhtd

Edit the server configuration file and remove HTTPS from the ClientConnectionMethods key. It should then look like:
ClientConnectionMethods NX,SSH

Then restart NoMachine server to make this change effective. On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --restart

 7.4. Using an Alternative Apache Web Server

Cloud Server is designed to provide a fully integrated service to deploy sessions on the web which doesn't require additional software to be installed or manual configuration. The minimal Apache web server, nxhtd, provides the necessary modules and is pre-configured to work with the web player application.

However, it is possible to run the web player application with an alternative Apache web server. This requires the configuration of Apache and the web player.

Instructions are available at: https://www.nomachine.com/DT11R00189

 8. Configure the Cloud Server

Most of the configurations can be done via User Interface in the server settings or via the remote administration UI. It's however possible to configure the behaviour of the cloud server manually via configuration files. Find here where these files are and how they work.

 8.1. Configuration Files

The configuration files for the nxserver and nxweplayer/nxwebrunner is server.cfg.
The configuration file for the nxnode program is node.cfg.
They are:
/usr/NX/etc/server.cfg and /usr/NX/etc/node.cfg on Linux
C:\Program files\NoMachine\etc\server.cfg and C:\Program files\NoMachine\etc\node.cfg for 64bit packages on Windows 64bit systems
C:\Program files (x86)\NoMachine\etc\server.cfg and C:\Program files (x86)\NoMachine\etc\node.cfg for 32bit packages on Windows 64bit systems
/Applications/NoMachine.app/Contents/Frameworks/etc/server.cfg and /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg on macOS.

The Default Configuration
All NoMachine Cloud Servers come with a default configuration that is sufficient to grant a working setup suitable for the majority of environments. In some cases, it can be however necessary to tune the configuration to fit, for example, company policies etc. You can change the configuration at any moment.

NoMachine configuration files are text files made up of a number of key-value pairs. All the configuration files can be edited manually by a text editor and an administrator user. For example 'vi' can be used on Linux and Mac, and 'notepad' on Windows. On Windows it can be necessary that you copy the cfg file in a different place, edit it and move it to the etc directory.

Be sure to uncomment the configuration key (i.e., remove the '#' pre-pended to the key) to set a value different from the default one.

When a configuration key supports an on/off status, set value to '0' to disable it and to '1' to enable it.

Make Changes to the Default Configuration Effective
In most cases, changes will be effective with the next new connection without the need to restart the server if not otherwise specified.

The list of keys which require a restart is available here: https://www.nomachine.com/AR07T01167

 9. Services Management

Installation and upgrade procedures take care of configuring and starting all the necessary services to make the Cloud Server fully operative without the need of further actions. The necessary services are configured to be restarted at each reboot of the host machine.

 9.1. Stopping and Starting Accepting Connections

Stopping the Cloud Server means that it will not accept new connections. All running sessions will stay running.

You can stop and start a Cloud Server from accepting new connections via:

the UI
from the Server status UI click on 'Stop the server': this will prevent users from running new connections.

Click on 'Start the server' to re-enable accepting new connections.

or from command line
on Linux and macOS run:

$ sudo /etc/NX/nxserver --stop
$ sudo /etc/NX/nxserver --start

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --start

 9.2. Shutting Down and Starting-up all Services

Shutting down a Cloud Server will terminate all the running sessions and shutdown all the NoMachine processes (nxserver, nxd, nxhtd etc ...).

Cloud Server and services can be shut down via:

the UI
in the Server status UI click on 'Shutdown the server'. When doing so, you will be asked if services must be started at the next reboot or not.

To start a Cloud Server and services, click on 'Start the server' in the UI.

or from command line.

On Linux and macOS:

$ sudo /etc/NX/nxserver --shutdown
$ sudo /etc/NX/nxserver --startup

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --shutdown
>  %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --startup

By default, all services will be restarted when the machine is booted. To override this behavior, specify the --startmode option ('manual' or 'automatic') when shutting down or restarting the services, on Linux and macOS:

$ sudo /etc/nxserver --shutdown --start-mode manual
$ sudo /etc/nxserver --shutdown --start-mode automatic
$ sudo /etc/nxserver --startup --start-mode manual
$ sudo /etc/nxserver --startup --start-mode automatic

On Windows:

 > %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --shutdown --start-mode manual
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --shutdown --start-mode automatic
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --startup --start-mode manual
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --startup --start-mode automatic

 9.3. Stopping and Starting nxd, nxhtd and nxsshd (Windows only)

These are the NoMachine services listening for connections:

You can stop a single service:

via the UI
in the Server settings -> Ports panel. You can choose there also the start mode: if the service must be started automatically at the next boot or not.

or from command line.

Stopping a service on Linux and macOS:

$ sudo /etc/NX/nxserver --stop nxd
$ sudo /etc/NX/nxserver --stop nxhtd

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop nxd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop nxhtd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop nxsshd

To start or restart a service on Linux and macOS:

$ sudo /etc/NX/nxserver --start nxd
$ sudo /etc/NX/nxserver --start nxhtd

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --start nxd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --start nxhtd
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --start nxsshd

The --startmode option ('manual' or 'automatic') can be set also for a single service, for example, on Linux and macOS:

 $ sudo /etc/nxserver --startmode nxhtd manual

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --startmode nxhtd manual

The nxserver --startmode command operates on the configuration keys listed below. You can change them manually in the server configuration.

Package for Windows includes a built-in SSH server, nxsshd. As an alternative, you can use the Microsoft SSH server as explained here: https://kb.nomachine.com/AR03S01117

 9.4. Discovering this Server on LAN

By default a Cloud Server broadcasts information to let other NoMachine computers to discover it on the local network. You can disable this feature via:

the UI
in the Server settings -> Ports panel uncheck 'Advertise this computer on the local network'

or in the server configuration file
set the following key in the server configuration:

EnableNetworkBroadcast 0

Then restart the server to make changes effective, this will terminate all the running sessions. On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --restart

Also the NoMachine server on the node is able to broadcast its information over the LAN when it has direct access enabled.

 10. Local User Management

System accounts can have different NoMachine-related privileges, they can become trusted users or administrators and have always access to the physical desktop of the Cloud Server, even without the need of the owner's approval.

 10.1. Managing Local System Accounts on the Cloud Server Host

You can manage (create, delete and modify) system accounts on a Cloud Server host by using tools provided by the Operating System.

Otherwise use the server commands, the account will be created with the default system settings. On Linux and macOS:

$ sudo /etc/NX/nxserver --useradd USERNAME --system

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useradd USERNAME --system

To delete the user's system account on Linux and macOS:

$ sudo /etc/NX/nxserver --userdel USERNAME --system

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userdel USERNAME --system

To change the user's system password on Linux and macOS:

$ sudo /etc/NX/nxserver --passwd USERNAME --system

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --passwd USERNAME --system

To assign a password only for NoMachine different from system password to a system user, enable NoMachine Password DB EnablePasswordDB 1

Then execute 'nxserver --useradd USERNAME' and set the NoMachine password for that user. The user should have already a system account.

To change the NoMachine password when NoMachine Password DB is enabled, execute 'nxserver --passwd USERNAME' and set the new NoMachine password for that user.
To verify if the user's authentication is based or not on NoMachine Password db, use 'nxserver --userauth USERNAME'

Enabling and Disabling access for a NoMachine User

Prerequisites are:

(i) The user has run at least one session or has been added to NoMachine dbs by means of 'nxserver --useradd' command.

(ii) NoMachine Users DB is enabled (EnableUsersDB 1 is set in server.cfg)

By default, all users are allowed to access a Cloud Server. You can disable/enable a user and forbid/allow access to the Cloud Server by running, on Linux and macOS:

$ sudo /etc/NX/nxserver --userdisable USERNAME
$ sudo /etc/NX/nxserver --userenable USERNAME

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userdisable USERNAME
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userenable USERNAME

Listing the NoMachine Users

All users who have run at least one session or have been added to NoMachine DBs are stored in the Users db. The --extend flag is optional. You can retrieve the complete list by running on Linux and macOS:

$ sudo /etc/NX/nxserver --userlist [--extended]

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userlist [--extended]

The output of this command provides the following fields:

Username: the account name used to log-in by NoMachine.

NX administrator: it displays if the user has NoMachine administrator's privileges or not.

Redirected to: IP/hostname of the server to which the user's connection is redirected (by means of the 'nxserver --redirect' command).

Trusted physical for: it shows if the user is trusted for connections to physical desktops for 'all nodes and users', some of them or node.

Trusted virtual for: it shows if the user is trusted for connections to Linux virtual desktops for 'all nodes and users', some of them or node.

Screen Sharing: it shows if the user has the sharing of his/her physical screen enabled or disabled (it's the Desktop shared/Desktop not shared entry in the NoMachine menu of the !M icon in the system tray.

Access: it shows if the user is enabled or not to access the NoMachine system. This works in conjuction with the use of the NoMachine Users DB: when enabled (EnableUserDB 1 in the server configuration), it's possible to enable/disable user's access to the whole NoMachine system.

Forwarded to: it indicates to which node, if any, the user will be forwarded when connecting to the Cloud Server.

10.2. Connecting to the Local Physical Desktop

By default, all users except Guests, are allowed to connect to the physical desktop of the Cloud Server. This corresponds to the following setting in server.cfg:
PhysicalDesktopAccess administrator,trusted,owner,system

administrator: system adminstrators and NoMachine administrators
trusted: NoMachine trusted users for connections to the physical desktop (nxserver --useredit USERNAME --trusted physical)
owner: the owner of the remote desktop
system: all unprivileged users who have a valid account to log-in, included System Guest Users who have a system account generated automatically on demand. They are available only on Linux with NoMachine Terminal Server and Enterprise Terminal Server.

System users by default must be authorized to connect by the desktop owner. Administrators, trusted users and the desktop owner instead can connect without the need of authorization. This corresponds to the following setting:
PhysicalDesktopAccessNoAcceptance administrator,trusted,owner

Add or remove any of the available user's types to the PhysicalDesktopAccess and PhysicalDesktopAccessNoAcceptance keys to manage who can connect to the physical desktop of the Cloud Server and if the desktop owner is requested to accept or refuse the incoming connection,

Login as 'root' (Linux and macOS) or 'administrator' (Windows)

A Cloud Server allows by default administrative users to connect. You can disable it by setting in the server configuration:
EnableAdministratorLogin 0

To re-enable the possibility to log in as root or administrator, set:
EnableAdministratorLogin 1

Making a user 'NoMachine administrator'

Making a user 'NoMachine administrator' gives the user some privileges valid only for NoMachine, mainly the ability to add nodes to the Cloud Server via UI and to connect to the physical desktop. This doesn't affect his/her system privileges. Also an unprivileged system user can be made NoMachine administrator.

To make a user becoming a NoMachine administrator on Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --administrator yes

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --administrator yes

To remove NoMachine administrator's privileges, on Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --administrator no

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --administrator no

Making a user trusted for NoMachine

To make a user trusted for connecting to the physical desktop of a Cloud Server, run on Linux and macOS

$ sudo /etc/NX/nxserver --useredit USERNAME --trusted physical

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --trusted physical

To remove the 'trusted' privileges, execute on Linux and macOS:

$ sudo /etc/NX/nxserver --useredit USERNAME --trusted none

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --trusted none

You can specify the --trusted attribute also when creating a new system user, by means of 'nxserver --useradd USERNAME --system --trusted physical'

10.3. Disabling Access to the Local Physical Desktop

To completely forbid access to the physical desktop, set the PhysicalDesktopAccess key in server.cfg to 'none':

PhysicalDesktopAccess none

In this way, nobody will be able to connect by NoMachine to the physical dekstop of the Cloud Server host.

 11. Updates

This section will explain how to keep your cloud server installation and nodes always up-to-date. Automatic updates from NoMachine repositories are also supported.

11.1. Updating Manually

It's possible to update installations by clicking on the NoMachine package icon or via command line as explained in the Chapter of this guide related to Install, Update or Remove the software.

11.2. Using the Automatic Updates

The Cloud Server, as well as the other NoMachine client and server products, periodically checks NoMachine repositories (by default every two days) to verify if updates are available and will prompt a dialog informing the user that a new version is available.

It will never automatically update the current installation. Also the download in background of a new software version will not lead to an automatic update of the current installation.

 11.3. Updating Cloud Server and Nodes (v. 8)

Updating the NoMachine server installation requires the termination of all the running sessions on that host. These sessions cannot be recovered later. This is necessary for installing the new libraries and binaries. Processes already loaded in the system memory lock down the corresponding binaries and libraries that cannot be otherwise replaced.

The procedure implies a shutdown of all services. They are automatically restarted once the update procedure is completed.

The cleanest way to upgrade a Cloud Server and its nodes is to:

1. initially update installation on the nodes, then
2. update installation of the Cloud Server or both Cloud Servers if two Enterprise Cloud Server Cluster are set-up in a failover cluster.

As a precaution, we suggest to do the following before proceeding with the upgrade.

Step 1- Stop the node(s) you're going to update.
This will prevent new connections to the node(s) but will not terminate sessions there. You can stop access to the node(s) from the Cloud Server host as explained below.

On Linux and macOS, execute the command as 'sudo' user or as 'root' (and without 'sudo'):

$ sudo /etc/NX/nxserver --nodestop UUID

UUID is the UUID of the node as it appears in the output of the 'nxserver --nodelist --extended' command.

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodestop UUID

Step 2- Then, proceed to update the node. You can do that by installing a new package or via UI by means of the automatic updates from the NoMachine repositories. (See next paragraph for more details).

Step 3- Finally, re-enable accepting connections on the nodes by running the following commands on the Cloud Server host.

On Linux and macOS:

$ sudo /etc/NX/nxserver --nodestart UUID

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --nodestart UUID

The 'nxserver --nodestop' and 'nxserver --nodestart' commands accept a comma-separated list of nodes in the format of: UUID,UUID2...
where UUID1 is the UUID of the first node as it appears in the output of 'nxserver --nodelist --extended' etc...

Step 4- Once all nodes have been updated, update the Cloud Server installation. Let's distinguish two cases, a single Cloud Server (Case I) or two Cloud Servers in a failover cluster (Case II).

Case I - Updating a single Cloud Server

Stop accepting connections on the Cloud Server host by executing the following commands.

On Linux and macOS:

$ sudo /etc/NX/nxserver --stop

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop

Update the Cloud Server. The update procedure will restart automatically all the necessary services.

Case II - Updating the Cloud Server failover cluster

Step 1- Shutdown the Cloud Server on the secondary server host to avoid activating the failover procedure when stopping the Cloud Server on the primary server host.
To do that, execute the following command on the secondary server host.

On Linux and macOS:

$ sudo /etc/NX/nxserver --shutdown

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --shutdown

Step 2- Then stop accepting connections on the active Cloud Server by executing the following commands.

On Linux and macOS:

$ sudo /etc/NX/nxserver --stop

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --stop

Step 3- Now update the primary Cloud Server and the secondary Cloud Server. Order of update is not relevant.

Step 4- Finally restart both Cloud Servers after the update to make sure that the cluster interface is created on the primary server. Execute firstly on the primary ECS host then on the secondary WECS host the following command.

On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows, open a CMD console as administrator and execute:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --restart

 11.4. Upgrading from v6 or v7 to v8

Upgrade before the nodes (even in more steps) and finally the Cloud Server. The detailed procedure is explained at paragraph 'Updating Enterprise Cloud Server Cluster and Nodes'.

Via Automatic Updates
Upgrade from v6 requires to upgrade before to v7 and then to v8.

Via command line
It's possible to upgrade a Cloud Server environment from v6 or v7 to v8 by installing the appropriate package v8 according to table at: https://kb.nomachine.com/AR12S01147.

Subscriptions v6 and v7 are compatible with v8, except those cases which require to replace the old license with a subscription v8. Please see table here: https://kb.nomachine.com/AR12S01147

Note that since v8 there will be only a single license file, server.lic, for each server side product, including for Enterprise Terminal Server Node. When replacing license 7 is not needed, the old node.lic file will be simply ignored by server v8, no further actions are required.

 12. Logging Facilities

NoMachine logs by default to its 'log' directory and has eventually log rotation capabilities. Alternatively, you can configure NoMachine to log to system logs.

To retrieve logs by using the NoMachine tools, please refer to guides in the Configuration section at: https://www.nomachine.com/all-documents to Collect server side logs automatically or to Collect server and client logs manually.

When debug mode is enabled, server logs may increase consistently. It's suggested to keep debug level only for the time necessary to reproduce the problem and collect logs

 12.1. Enabling NoMachine Log Rotation

Once activated, in the default configuration, logs are rotated once per month when they exceed 100MB. If not otherwise specified, NoMachine preserves up to seven rotated files and deletes the oldest ones.

Rotated logs are saved in the following directories:
/usr/NX/var/log/logrotate on Linux
%PROGRAMDATA%\NoMachine\var\log\logrotate on Windows
/Library/Application Support/NoMachine/var/log/logrotate on macOS.

Command to activate log rotation is on Linux and macOS:

$ sudo /etc/NX/nxserver --logrotateadd OPTION

and on Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --logrotateadd OPTION

OPTION can be any of the following:
--rotate VALUE, specify the maximum number of rotated files to be preserved in the logrotate directory. When this number is exceeded, the oldest files are deleted.
--time-interval TIME, specify the frequency of log rotation. Frequency can be specified in seconds or by using the 'Daily', 'Weekly', 'Monthly', or 'Yearly' keyword. Rotate logs when the interval of time and the minimum log size is reached.
--min-size VALUE, specify the minimum file size for rotating logs according to the given interval of time. If the minimum size is not reached, logs are not rotated. Value is by default in kilobytes, add M or G to set it in megabytes or gigabytes respectively.
--size VALUE, specify the minimum file size for applying log rotation as soon as the file size is reached, regardless of the frequency set for log rotation.
--compress yes|no, by default each log file is compressed as a gz archive, use '--compress no' to not compress it.
--destination PATH, provide an alternative path where to store the rotated files. If OPTION is not specified, the default settings will be applied.

By default, log rotation is applied to all NoMachine log files. It's however possible to specify which log file should be under log rotation. On Linux and macOS:

$ sudo /etc/NX/nxserver --logrotateadd LOG OPTIONS

and on Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --logrotateadd LOG OPTIONS

LOG can be any of these files:
nxserver.log
nxerror.log
nxd.log
nxservice.log (on Windows only)
nxwebrunner.log
nxhtd-error.log
nxhtd-access.log

If OPTION is not specified, the default settings will be applied.

Other commands to manage log rotation

List current settings for log rotation:

nxserver --logrotatelist

Edit parameters set for log rotation:

nxserver --logrotateedit LOG OPTION

Delete all settings for log rotation:

nxserver --logrotatedel

Delete log rotation settings for a specific log file::

nxserver --logrotatedel LOG

It's possible to force log rotation at any moment. This doesn't require you to enable it.
This can be helpful for example to debug a problem which is easily reproducible:
- clean up logs with 'nxserver --logrotate'
- activate the debug log level with 'nxserver --debug --enable all'
- reproduce the problem
- collect logs with 'nxserver --debug --collect'
- and finally restore informational log level with 'nxserver --debug --disable all'

To apply log rotation to all files or to a given log only:
nxserver --logrotate LOG OPTIONS

OPTION can be any in this case any of the following options:
--compress yes|no, by default the log file is compressed as gz archive, use '--compress no' to not compress it.
--destination PATH, provide an alternative path for where to store the rotated files.

 12.2. Using the System Logging Facilities

It's possible to configure nxserver, nxwebplayer/nxclient and nxnode programs to log to the system log file. Edit the server.cfg and node.cfg files, uncomment and set:

EnableSyslogSupport 1

Then restart the server and all services to make the change effective. On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --restart

 12.3. Understanding Error Messages

The following list reports common error messages displayed in the UI to the end-user when for some reason the client cannot connect to the remote host and actions to fix them, when possible.

1. Host not found
Check IP or hostname and ensure that they are correct. If you're connecting over the internet, be sure to provide the external IP of the server host. 

2. No route to host
This indicates that the remote compure is not reachable. Ensure that it's connected over the internet and port 4000 is open (default for connections by NX protocol).

3. Connection refused
The server refused the connection. Verify that NoMachine is listening on the port where you are trying to connect and that such port is open in the firewall.

4. Connection reset by peer
The connection has been interrupted on server or client side. Logs on server or client side should provide more info.

5. The service was shut down
NoMachine services on the remote computer are not up and running. You may try to restart them via UI or by 'nxserver --startup' from command line.

6. Node/Server is not responding
The remote host is no longer responsive. This could indicate a network problem.

7. Could not access node/server certificate
The certificate for host key verification stored on the server backend cannot be retrieved. Running 'nxserver --configupdate' on the Cloud Server could fix the problem. In case of inverse connection, run 'nxserver --configupdate' on the node.

8. Host key verification failed
The verification of authenticity of remote host failed because the user didn't accept the certificate.

9. Key-based authentication failed
Authentication between server and node or between node and server failed. This can happen when the server has been reinstalled on any of these machines. For direct connection, run on the Cloud Server host 'nxserver --nodereadd NODE'. For inverse connection run on the node: 'nxserver --serverreadd NODE'

10. The version on the node/server is not supported
NoMachine version of the Cloud Server and of the server installed on the node are not compatible and must be aligned.

11. The subscription on the node/server is missing
Ensure that server.lic is properly installed on the server host.

12. The subscription on the node/server is expired
NoMachine server stops to work when the license is expired. Ensure to acquire a new license and replace it. If it's an evaluation version, uninstall the server package and reinstall it to get further 30 days for try.

13. The subscription on the node/server is not suitable for this product
Be sure that server.lic is suitable for the package type that is installed.

14. The subscription on the node/server doesn't match platform
Be sure that server.lic is suitable for the Operating System.