Introduction

Welcome to the NoMachine Enterprise Terminal Server - Installation and Configuration Guide v. 9.

1. NoMachine Enterprise Terminal Server Installation and Configuration Guide

---

What is NoMachine Enterprise Terminal Server for?
NoMachine Enterprise Terminal Server is a standalone server for Linux that allows unlimited concurrent virtual desktops distributed on multiple machines (nodes). Designed for setting-up a multinode environment, it works in conjunction with NoMachine Enterprise Terminal Server Node(s).

The multi-node system provides individual instances of the remote desktop (terminal services) and gives users their own personal desktop environment. Each user has his/her own desktop or application, store and manage files inside the session and, in case, share his/her own resources with another user. The session load can also be balanced among the nodes according to different methods (load-balancing).ver cluster) .

Available for Linux, the Enterprise Terminal Server accepts connections via a browser (thanks to its built-in web server) or via the NoMachine client.

Additionally, it can also become a node of any of the Cloud Server products. This solution is suitable to centralize access to multiple NoMachine servers distributed across a LAN or WAN environment.

A Graphical Interface
The NoMachine Enterprise Terminal Server package includes a User Interface (UI) for administering the server and its services (Server settings).

Most common operations detailed in this guide can be performed by the NoMachine UI and the Server settings panel running on the local installation of the server.

More details about the Server UI can be found in the dedicated guide available in the Documents section at: https://www.nomachine.com/all-documents

The Enterprise Terminal Server comes also with a client UI for running sessions and connecting to other remote desktops. The same UI can be also used by administrators to administer another NoMachine server remotely. This remote administration UI mirrors the local NoMachine server UI and allows to perform the same operations.

The server is fully operative once installed
Installation provides a fully operative NoMachine server with a default configuration suitable for the majority of environments. All the necessary services are automatically started.

An autonomous server or a node of a cloud server
NoMachine Enterprise Terminal Server works as a single server or standalone server. NoMachine Enterprise Terminal Server supports unlimited concurrent virtual desktops distributed among its Enterprise Terminal Server Nodes and -by default- its host machine. A virtual desktop is a personal instance of the remote Linux desktop. Sharing of a virtual desktop is also supported. The number of users is not limited. If the Enterprise Terminal Server is used as node of a NoMachine cloud server, it still accepts direct connections to its IP/hostname, unless configured differently.

Deploy the server host on NoMachine Network
If you want to connect to the server via NoMachine Network, you need to add its host machine to Network (this is free) and acquire a NoMachine Network subscription for each user. With NoMachine Network it's not needed to assign an external IP to the server or open ports in the firewall.

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.

InstallationDirectory
is: BaseDirectory/NX, i.e. /usr/NX.

Configuration files
Configuration files are /usr/NX/etc/server.cfg and /usr/NX/etc/node.cfg.

The command line interface
NoMachine server and node programs have a command line interface to execute operations.

You need to be a privileged system user to access all these functionalities. These commands can be run from an xterm or similar using the sudo utility or as root and without 'sudo'.

Invoke the 'nxserver' and 'nxnode' programs from /etc/NX, for example:

$ sudo /etc/NX/nxserver  --status
Printing the server and node usage doesn't require to be a privileged user, instead:
$ /etc/NX/nxserver  --help
$ /etc/NX/nxnode  --help
The 'nxserver --help' and 'nxnode --help' display the list of all the available commands and options and their description.

Online Resources
Visit the NoMachine Support Area to access a variety of online resources including the NoMachine Forums, tutorials and FAQs: https://www.nomachine.com/support. Or log in to your customer area to open a support enquiry.

Find a list of all documents and tutorials: 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 the Server

---

In order to have a fully working NoMachine setup immediately after installation and without the need for further operations, the installation procedure takes care of automatically starting all the required services, including the built-in Apache-based web server nxhtd. In order to work in all possible environments the nxhtd service as well as the Apache web server are configured to listen on all interfaces (0.0.0.0).

2.1. Prerequisites

Supported Operating Systems
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 37
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:
Linux 195 MB

Software requirements
A desktop environment must already be installed. This applies also to headless Linux machines. Connections by the web and by NoMachine clients are supported.

Compatibility with older versions
Even if it's advisable to upgrade client installations to the same version 9 of the Enterprise Terminal Server, compatibility with clients v. 8 and 7 is preserved.
A Enterprise Terminal Server v. 9 can work as a node of Cloud Server v. 8, even if it's preferable to upgrade the whole setup to v. 9.

2.2. 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 downloading the package from your Customer Area: https://www.nomachine.com/support#login.

Successive updates
The update procedure for server and node installations requires all NoMachine services to be stopped in order to correctly replace libraries and binaries. This implies that the Enterprise Terminal Server is not accessible to users during the update procedure. Current sessions will be terminated, users will be able to connect again later.

There are two ways to update your current installation:

1. Automatic updates

   You can update your installation from our repositories. Just run the NoMachine User Interface from your Programs Menu and open the Server -> Settings -> Updates panel and click on the 'Check now' button. Follow the prompts to continue updating the software.NoMachine has the automatic check for updates enabled: it will check the 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 the Documents section on the NoMachine web site: 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 you download the package from your Customer Area: https://www.nomachine.com/support#login.
   

2.3. 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:
# rpm -qa | grep nomachine

UPDATE

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

UNINSTALL

# rpm -e  nomachine-enterprise-terminal-server

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-terminal-server

2.4. DEB Packages

If you want to install to the 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:
$ dpkg -l | grep nomachine

UPDATE

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

UNINSTALL

$ sudo dpkg -r nomachine-enterprise-terminal-server

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-terminal-server

2.5. TAR.GZ Packages

If you want to install to the 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.6. Installing the License (for Customers)

Customer packages
include a temporary (30-days) server.lic file for evaluation.
This license file has to be replaced with the customer's license file acquired from NoMachine 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).

The Enterprise Terminal Server will cease to work once the license is expired. Nodes with an expired license are automatically excluded from the load balancing. If they are available for the manual node selection, they are still shown in the UI but their status is marked as 'failed' since they are unable to accept connections.

You may contact your NoMachine provider or the Support Team for renewal options.

To verify from command line that server.lic is correctly in place and check its validity, you can run:

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

3. Setting-up a Multinode Environment

---

A NoMachine multi-node environment is made up of a central server (the Enterprise Terminal Server) and nodes (Enterprise Terminal Server Nodes) to which the server sends connection requests. Note that only the Enterprise Terminal Server is able to accept direct connections to its host, it acts as a single point of access to the nodes. An Enterprise Terminal Server Node is not a server, it refuses all direct connections and can work only behind an Enterprise Terminal Server. By default, virtual desktops can be started also on the Enterprise Terminal Server host.

When the user connects to the Enterprise Terminal Server, traffic is tunneled from the client to the Enterprise Terminal Server Node via the server.

To set-up the multinode environment:
Step 1- Install NoMachine Enterprise Terminal Server on machine A. Install the customer's license file, server.lic.

Step 2- Install NoMachine Enterprise Terminal Server Node on machine B. Install the customer's license file, server.lic.

Step 3- Add the node to the server.

Short instructions to setup a default multinode environment are available here: https://www.nomachine.com/AR07P00987.

The multi-node setup will automatically make available the Enterprise Terminal Server Nodes for the automatic load balancing of virtual desktop sessions among such nodes and the Enterprise Terminal Server host. The last can be excluded from the list for load-balancing.

If needed, you can activate the manual node selection of the nodes. It means that all users, or only some specific users, will be able to choose on which node to create their virtual desktop.

It's recommended to keep versions of Enterprise Terminal Server and Enterprise Terminal Server Nodes always aligned to the same version.

3.1. Adding a Node to the Server

You can add the Enterprise Terminal Server Node from the NoMachine User Interface.
Ensure to have an account with NoMachine administrator's privileges, this will not affect system user's privileges. To assign NoMachine administrator's privileges:

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

Then connect via NoMachine client to the Enterprise Terminal Server as a NoMachine administrator. Click on the 'New node' button to add the Enterprise Terminal Server Node.
Step-by-step instructions are available in the corresponding guide in the Tutorials section on our web site: https://www.nomachine.com/all-documents.

Otherwise you can add the node from command line.
Execute the following command on the Enterprise Terminal Server Host:

$ sudo /etc/NX/nxserver --nodeadd NODE  --node-name NAME_of_NODE  OPTION 

where NODE is the IP or hostname of the EnterpriseTerminal Server Node, NODE_NAME is the name to be assigned to that node. Assigning a name to the node is mandatory. OPTION is any of the accepted parameters listed in the table below.

When running the --nodeadd command, NoMachine Enterprise Terminal Server tries to connect to the node. If it cannot authenticate using NoMachine server's public key, it will ask you to login as a privileged user to that node and will try to add the server public key there. It's therefore necessary to have an account with administrative privileges on each Enterprise Terminal Server Node.

You can specify settings different from the default ones while adding the node or later by editing it. The available options are:

Description	OPTION
Connection to the node uses by default NX protocol and port 4000. Use the --protocol option to set a different protocol.	--protocol NX|SSH
Specify port for the selected protocol. Default is 4000 for NX and 22 for SSH.	--port PORT
Add or remove a node from the list of nodes available for the automatic load balancing of virtual desktops.	--load-balancing yes|no
Include or exclude the node from the list of available nodes displayed in the client UIs. Manual selection is enabled by default but won't work unless the profile rule for manual-node-selection is also enabled.	--manual-selection yes|no
Allow to specify a longer note (1024 characters) for the node.	--comment COMMENT
Specify a weight for the node. Weight is used when the server is configured to use a custom algorithm for load-balancing virtual sessions. This value is used by the NoMachine custom script for weighted round-robin.	--weight WEIGHT
Set the maximum number of concurrent connections allowed on that node. This value is used by the Nomachine custom script for weighted round-robin.	--limit LIMIT
Set --strict-host-key-checking to 'no' for adding automatically the host key to the known_hosts file (if SSH protocol is used) or to client.crt (if NX protocol is used) on the server without being prompted to accept that key.	--strict-host-key-checking yes|no
Add the node to an already existent group of NoMachine nodes.	--node-group NODE_GROUP_NAME

Some examples
Add a node with default settings:

$ sudo /etc/NX/nxserver --nodeadd testdrive.nomachine.com  --node-name "Test Drive machine"

Exclude node 'testdrive.nomachine.com:4000' from the load-balancing list:

$ sudo /etc/NX/nxserver --nodeedit testdrive.nomachine.com:4000 --load-balancing no

List information about the node(s)

$ sudo /etc/NX/nxserver --nodelist
$ sudo /etc/NX/nxserver --nodelist NODE:PORT

Synchronize node information on server side:

Use this command when some settings or configurations have been changed on that node, for example a new desktop environment has been installed and a setting in node.cfg has been changed. The 'nxserver --nodeedit' command will update the list of available resources for that node in the Enterprise Terminal Server backend.

$ sudo /etc/NX/nxserver --nodeedit NODE:PORT

where NODE:PORT is the unique name of the Enterprise Terminal Server Node, as it appears in the list of the available nodes.

Edit settings of a node

$ sudo /etc/NX/nxserver --nodeedit NODE:PORT OPTION

Remove a node

$ sudo /etc/NX/nxserver --nodedel NODE:PORT

3.2. Managing Groups of Nodes

Groups of NoMachine nodes allow to set profile rules only for specific pools of nodes. The same node can belong to more groups.

Using groups of nodes (Enterprise Terminal Server Nodes)
Create the group:

$ sudo /etc/NX/nxserver --nodegroupadd GROUP

where GROUP is the name of the group of nodes.

Add a node, which is already part of the multinode environment, to the group:

$ sudo /etc/NX/nxserver --nodeedit NODE:PORT --node-group GROUP

where NODE:PORT is the name of the node as it appears in the output of the 'nxserver --nodelist' command.

It's also possible to specify the group while adding the Enterprise Terminal Server Node to the Enterprise Terminal Server:

$ sudo /etc/NX/nxserver --nodeadd NODE --node-group GROUP

Then set the profile rule with the --node-group GROUP option to apply the rule only to those Enterprise Terminal Server Nodes in that group.

To remove a node from the group:

$ sudo /etc/NX/nxserver --nodedel NODE:PORT --node-group GROUP

To delete the nodes group:

$ sudo /etc/NX/nxserver --nodegroupdel GROUP

To list all groups of nodes:

$ sudo /etc/NX/nxserver  --nodegrouplist

3.3. Configuring Load-Balancing of Virtual Desktops and Manual Node Selection

It's possible to configure NoMachine Enterprise Terminal Server to manage the following alternative configurations:

1. Load-balancing of virtual desktops: the server will automatically choose the node where to start the session. This is the default.
2. Manual node selection of virtual desktops: the user will have the possibility of choosing the remote node where to create the virtual desktop.
3. Load-balancing of virtual desktops and manual node selection.

To verify current settings, run:

$ sudo /etc/NX/nxserver --resourcelist --class feature

and check if the node-load-balancing and manual-node-selection features are set to 'yes' or 'no'.

Settings for load-balancing and manual node selection can be modified via profile rules. If rules have been explicitly set, you can verify current settings also by running:

$ sudo /etc/NX/nxserver --rulelist --class feature

The following alternative configurations apply to the whole system, i.e. they apply to all users.

Configuration I
This is the default configuration. The server will use only automatic load-balancing and rely on any of the available load-balancing algorithm to choose the node where the virtual desktop will be started. The manual node selection is disabled.

Profile rules to set-up this configuration are:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type node-load-balancing --value yes
$ sudo /etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value no

Configuration II
The server will allow users to choose the remote node (manual node selection) where to start their virtual desktops. The automatic load-balancing of sessions is disabled.

Profile rules to set-up this configuration are:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type node-load-balancing --value no
$ sudo etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value yes

Configuration III
The server will load-balance virtual desktops according to any of the available algorithms and will allow the manual selection of the nodes as well. It's possible to configure a node only for load-balancing or manual selection.

Profile rules to set-up this configuration are:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type node-load-balancing --value yes
$ sudo /etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value yes

To configure a node to the manual node selection only, exclude it from the load-balancing list by executing:

$ sudo /etc/NX/nxserver --nodeedit NODE:PORT --load-balancing no

Configuring load-balancing and manual node selection on a per-user basis

The previous configurations I, II and III can be also set on a per-user or per-group of users basis by specifying the --user USERNAME and --group GROUPNAME options respectively. The group of users can be a system user or a NoMachine group.

Some examples
The following examples assume to have a default environment (multi-node support and load-balancing enabled and manual node selection disabled for the whole system).

Allow user 'nomachine' and the users' group 'devels' to use both the load-balancing and the manual node selection:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value yes --user nomachine
$ sudo /etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value yes --group devels

Allow the user group 'writers' to use only the manual node selection:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type manual-node-selection --value yes --group writers
$ sudo /etc/NX/nxserver --ruleadd --class feature --type node-load-balancing --value no --group writers

Limiting the number of virtual desktops on each Enterprise Terminal Server Node

The following profile rule permits to set the maximum number of concurrent virtual desktops that can be run on each of the available nodes:

$ sudo /etc/NX/nxserver --ruleadd --class node --type virtual-desktops-limit --value VALUE

where VALUE is the maximum number of virtual desktops.

It's also possible to set the limit on a per-node basis:

$ sudo /etc/NX/nxserver --ruleadd --class node --type virtual-desktops-limit --value VALUE --node NODE:PORT

where NODE:PORT is the name of the Enterprise Terminal Server Node, as it appears in the output of the 'nxserver --nodelist' command.

3.4. Load-balancing Algorithms

NoMachine Enterprise Terminal Server supports multiple alternatives to manage the load-balancing of virtual desktops:

1. Plain round-robin algorithm
2. Weighted round robin algorithm (default)
3. Custom algorithm
4. Load average
5. System Load

CONFIGURATION I - Plain round robin algorithm
To make the server using a plain round-robin algorithm, set in the server configuration file:
LoadBalancingAlgorithm round-robin

CONFIGURATION II - Weighted round robin algorithm (default)
As for configuration I, the following key has to be set in the server configuration file:
LoadBalancingAlgorithm round-robin

In order to apply the weighted round algorithm it's necessary to assign a weight to at least one of the remote nodes (all nodes which don't have weight set, have weight 0 by default). If weight is not assigned, this algorithm is equivalent to a plain round-robin.

The node with the higher weight is the node where the session will be started first. If the limit for connections on the node is reached, the algorithm falls back to choose the first node provided by the server list.

A weight can be assigned while adding the node by using the '--weight WEIGHT' option or can be specified later by editing the node:

$ sudo /etc/NX/nxserver --nodeedit NODE --weight WEIGHT

For example:

/etc/NX/nxserver --nodeedit testdrive.nomachine.com:4000 --weight 1

CONFIGURATION III - Custom algorithm
You can create a custom script according to your needs. The custom load-balancing script has to be written in Perl and Perl has to be installed on the system.

To use a custom algorithm for load-balancing of virtual desktops set in the server configuration file:
LoadBalancingAlgorithm custom

Then provide path and name to the custom script in the following server configuration key:
NodeSelectionScript "/usr/NX/scripts/lb/nxweightedroundrobin.pl"

The installation package comes with a custom script: /usr/NX/scripts/lb/nxweightedroundrobin.pl written in perl and intended to provide an example.

The algorithm of this script, given a weight for each node and a limit of connections for that node, selects the node with a higher weight counted as:
weight = [weight of node] - [number of sessions connected to the node]

The following environment variables are available in the script: NX_USERNAME and NX_CLIENT_IP.
In this way the custom load-balancing algorithm may take into account which user is connecting and for example force the server to start the session on a particular node.

Note that the server passes to the custom script only those nodes that are effectively available to the user.

CONFIGURATION IV - Load average
The server can be configured to choose the node with the minimum load average. To apply this configuration, edit the server.cfg file and set:
LoadBalancingAlgorithm load-average

CONFIGURATION V - System load
The server can be configured to choose the node with the lowest system load calculated according to the algorithm specified in the /usr/NX/scripts/lb/nxreportsystemload.sh script set on the node.

By default, the algorithm takes in account the CPU Run Queue normalized by CPUs/Cores and I/O Wait and applies the following calculation:

load = (procs_running / cpus) + procs_blocked

This calculation can be edited in the nxreportsystemload.sh script and adapted to different situations.

To apply this configuration, edit the server.cfg file and set:
LoadBalancingAlgorithm system-load
and restart the NoMachine server:

$ sudo /etc/NX/nxserver --restart

A Practical Example
Premises
Load-balancing is configured to use the Load-average algorithm. Two or more nodes have zero-load set. Some of these zero-load nodes are hosting NoMachine sessions in status disconnected. Other zero-load nodes don't have NoMachine sessions.

Requirement
According to the load-average algorithm, the server chooses the node with the minimum load. This doesn't take into account if sessions are already running or not on the node. It's instead necessary that the server chooses the zero-load node without NoMachine sessions as first option.

Solution
Adopting a custom script which sets a weight for each NoMachine session and uses a combination of load average and number of sessions to choose the node where to start a new session.

To use this script, named in our example 'customLoadAverage.pl':
1. Copy the script below to a directory accessible by the nx user, for example: /usr/NX/scripts/lb/.
2. Set read-execute permissions for the nx user.
3. Edit server.cfg and set:
LoadBalancingAlgorithm custom
NodeSelectionScript "/usr/NX/scripts/lb/customLoadAverage.pl"

The customLoadAverage.pl script is:

#!perl
##################################################################
#
#
# Copyright (c) 2012, 2016 NoMachine, http://www.nomachine.com.
#
# All rights reserved.
#
#
##################################################################
#
# nxSessionLoad indicates each nx session load value, by default
# we set it to 1, this means that each nx session will be equal to
# load 1.0
#
my $nxSessionLoad = 1;

#
# nodeCustomLoadAvg is the combination of load average and number of
# running sessions on node.
# nodeCustomLoadAvg = runningSessions * nxSessionLoad + loadAvg
#
my $nodeCustomLoadAvg = -1;
my $nodeSelected = undef;
if (! @ARGV)
{
#
# Return empty message and exit.
#
print "\n";
exit 1;
}

my @nodeList = split(/#/, $ARGV[0]);
foreach my $node (@nodeList)
{
if (! $node)
{
next;
}
elsif (! $nodeSelected)
{
#
# Initialize node.
#
$nodeSelected = (split(/,/,$node))[0] || undef;
}

#
# $nodeName is the UUID qualifying the node as it appears in the output of 
# 'nxserver --nodelist' command.
# $nodeWeight is the weight, a numeric value, attributed to the node.
# $nodeSessionRunning is the number of sessions connected to the node.
# $nodeConnectionLimit is the maximum number of connections allowed on that node.
# $nodeLoadAvg is the load average of the node.
#
my ($nodeName, $nodeWeight, $nodeSessionRunning, $nodeConnectionLimit, $nodeLoadAvg) = split(/,/,$node);
if (($nodeConnectionLimit != 0) && ($nodeSessionRunning >= $nodeConnectionLimit))
{
#
# Ignore the node if maximum number of connections is reached for that
# node. Unlimited connections are allowed on that node if variable
# $nodeConnectionLimit is set to 0.
#
next;
}

if ($nodeCustomLoadAvg != -1 && ($nodeCustomLoadAvg <= $nodeSessionRunning * $nxSessionLoad + $nodeLoadAvg))
{
#
# Select node with lowest custom load average.
#
next;
}

$nodeCustomLoadAvg = $nodeSessionRunning * $nxSessionLoad + $nodeLoadAvg;
#
# Set new node.
#
$nodeSelected = $nodeName;
}
if (! $nodeSelected)
{
print "\n";
exit 1;
}

#
# Return selected node to nxserver.
#
print "$nodeSelected\n";
exit 0;

Notes:

1. Variable my $nxSessionLoad = 1; indicates the load given to each NoMachine session, regardless of whether it is connected or disconnected.
   In this example it is set to 1, so by default every session will have 1.0 as load value. To set, for example, the load of each session to 0.5: my $nxSessionLoad = 0.5;
2. The script chooses the node with the lowest custom load average value. Custom load average value is calculated in this way:
   nodeCustomLoadAvg = runningSessions * nxSessionLoad + loadAvg
   where:
   runningSessions is number of sessions running on the node.
   nxSessionLoad is the load of each NoMachine session as described above.
   loadAvg is the load average value set for the node.

3.5. Setting-up Two Servers in a Failover Cluster

This feature is available only with product Enterprise Terminal Server Cluster.

3.6. A practical Example to Setup the Failover Cluster

Failover Cluster is available only with product Enterprise Terminal Server Cluster.

3.7. Managing the Failover Cluster

Failover Cluster is available only with product Enterprise Terminal Server Cluster.

3.8. Best Practice to Upgrade a Multi-Node Environment

Updating the installed software requires the termination of all the running virtual desktops (connected or disconnected). These sessions cannot be recovered later.

The cleanest way to upgrade a multi-node environment is to:
1. Initially update the installation on each of the nodes (Enterprise Terminal Server Node).
2. Then update server's installation.

A step-by-step guide to upgrade a multinode environment is available in the https://www.nomachine.com/all-documents section.

3.9. Propagating Configurations to the Nodes

A number of configuration keys are automatically propagated from the Enterprise Terminal Server to its nodes. Their values will be set in the correspondent keys on each node. These keys are:
in server.cfg
EnableLockScreen

in node.cfg:
DisplayMonitorIcon
EnableSoundAlert
ShowDesktopViewed
EnableScreenBlanking
EnableScreenBlankingEffect
ShowNotificationInfo

When setting a new value on the Enterprise Terminal Server, restart it to propagate the new value to all nodes:

$ sudo /etc/NX/nxserver --restart

The restart will disconnect all sessions running on the nodes and terminate those on the Enteprrise Terminal Server host, if any. If a restart is not possible, update the configuration by using:

$ sudo /etc/NX/nxserver --configupdate

All the other keys are not propagated automatically and must be set on each node. Value set on the node overrides value set on the Enterprise Terminal Server host.

As an alternative, it's possible to use profile rules to configure some behaviours on the nodes instead of using the configuration keys. Profiles rules set on the Enterprise Terminal Server can be applied to all nodes, to specific nodes only or to group of nodes. In general, profile rules don't override keys' settings.

4. Initiating a NoMachine Connection (end-user's side)

---

Pre-requisite: you need to have a valid account on the server host and the password cannot be empty. Your account can be a local account or a LDAP account or an AD account. NoMachine doesn't check if the source of the user's account information is for example LDAP or local account database. Be sure to configure the login in advance.

4.1. Connecting by Browsers Via Web Tools

Once installation is complete, the server is ready to go.

Point your browser on your device to:

https://SERVER:4443

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

E.g., if the 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 your account on the server host and connect.

Auto-reconnection is supported: when the connection is lost for whatever reason (including when browser's computer has entered sleep mode), the NoMachine web application will automatically try to reconnect for as long as the user keeps the web page open. If reconnecting is not possible, then the user will have to reconnect manually.

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.

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.

You can find a step-by-step tutorial for connections by the web in the 'Tutorials' section at: https://www.nomachine.com/all-documents

4.2. Connecting by NoMachine Client

Install NoMachine Enterprise Client on your device. You can use also the free version of NoMachine or whichever other server type; they all provide the client UI for connecting to remote computers.

You can find a step-by-step tutorial for creating virtual desktops in the 'Tutorials' section at: https://www.nomachine.com/all-documents. If you're using the Enterprise Client, please see its Installation and Configuration Guide in the 'Installation' section at the same web page above.

Auto-reconnection is supported: when the connection is lost for whatever reason (including when the client host has entered sleep mode), the client will automatically try to reconnect for as long as the user keeps the User Interface open. If reconnecting is not possible, then the user will have to reconnect manually.

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.

4.3. Creating a NoMachine VPN

The NoMachine built-in VPN service allows to setup your Virtual Private Network for NoMachine connections without the need to use a third party program. Each NoMachine client can start one single VPN: open the UI and click on the Add button to 'Add VPN connection'. More details are available here: https://www.nomachine.com/AR03U01193

This feature is not available with the free version of NoMachine.

4.4. Preventing Users from Storing their Credentials

To prevent NoMachine users from storing their credentials, use the EnableClientCredentialsStoring key in the server configuration file, server.cfg. 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

4.5. Connecting Without an Account (Guest Desktop Sharing)

This feature is mainly conceived for temporary and on-the-fly connections to the remote desktop, 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 mandatory.

With Guest Desktop Sharing, users are able to connect to the remote desktop without the need to have a valid account on that host. The desktop owner must grant access by authorising the guest's connection request.

Guest Desktop Sharing is available for connections to Linux virtual desktops (Virtual Guest Desktop Sharing) and to the physical desktop (Physical Guest Desktop Sharing) of the server host.

To enable Guest Desktop Sharing via UI:
(i) open the server UI on the server host
or
(ii) connect there via client and use the remote server administration UI.

Then enter Settings -> Server -> Security panel and check the 'Allow guest desktop sharing access on this server' option.

Enabling 'Allow guest desktop sharing access on this server' via server UI will activate both the Virtual and Physical Guest Desktop Sharing.

The Guest Desktop Sharing can be enabled also via server configuration.

Virtual Guest Desktop Sharing
Edit the server.cfg file on the node and ensure that 'guest' is listed:
VirtualDesktopAccess administrator,trusted,system,owner,guest
(Remove the pre-pending # from the key name).

Physical Guest Desktop Sharing
Edit the server.cfg file on the host where you want to enable guest access and ensure to have 'guest' in the list of values for this key:
PhysicalDesktopAccess administrator,trusted,system,owner,guest
(Remove the pre-pending # from the key name).

More in general, keys above allow to define which kind of user can access the remote desktop. Accepted values are:
administrator: system adminstrators and NoMachine administrators
trusted: NoMachine trusted users for connections to the physical desktop (nxserver --useredit USERNAME --trusted physical)
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.
owner: the owner of the remote desktop
guest: Guest Desktop Sharing users (which don't have a system account)

4.6. Enabling NoMachine 2FA

The NoMachine built-in 2FA (two-factor authentication) relies on the NoMachine Network service, you need to have a NoMachine Network account for using it (it's free) and install the NoMachine app for iOS and Android on your mobile device to receive push notifications. 2FA can be used to protect your identity against account takeover and/or to verify all connections to the desktop. Both functionalities can be activated via UI in the Settings -> Network -> Machine panel.

More details about NoMachine 2FA can be found here: https://www.nomachine.com/AR10Q01054

5. Configuring Web Sessions

---

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.

5.1. The Section "Server" (Web Player to Server Connection)

The configuration file for the web player program (which provides the graphical front-end) and the web client program (which manages web sessions) is server.cfg, located in /usr/NX/etc/.

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. To change the name to be displayed, it's necessary to enable also the EnableWebConnectionName key in server.cfg: EnableWebConnectionName 1

Host is IP or hostname of the NoMachine server host.
If different than localhost, it's then necessary to update manually the list of known hosts as explained here:
https://kb.nomachine.com/AR06P00984

Protocol specifies the protocol, NX or SSH, that the web player will use to connect to the NoMachine server. Default is:
Protocol NX
Port 4000

To use SSH protocol with default port, set:
Protocol system
Port 22

Port indicates the listen port for the server, by default 4000 for connections by NX protocol, 22 for connections by SSH protocol on Linux.

This setting has to be changed only when NoMachine is configured to listen on a non-default port. Changing the port for web connections requires a manual procedure available here: https://kb.nomachine.com/AR06N00888.

Authentication defines the authentication method to be used when connecting by the web, by default 'password':
Protocol NX
Authentication password
and:
Protocol SSH
Authentication password

Key-based authentication is supported at the moment only for NX protocol, instructions to set it up are available here: https://kb.nomachine.com/AR03Q01020.

NoMachine uses by default port 22 for SSH protocol on Linux. 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 it's necessary to modify the listening port for the SSH server on the system.

Other settings in server.cfg specific for web sessions are qualified by the 'Web' keyboard in their name.

Showing hostname or a custom label
To display hostname or IP of the 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

Start and stop the web server
You can start and stop the NoMachine HTTP server (nxhtd) from the UI in the Settings -> Server -> Ports panel. From the NoMachine User Interface you can also change the port where the web server will be listening (by default 4443.

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

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

Stop, start or restart nxhtd

$ sudo /etc/NX/nxserver --stop nxhtd
or:
$ sudo /etc/NX/nxserver --start nxhtd
or:
$ sudo /etc/NX/nxserver --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:

$ sudo /etc/NX/nxserver --startmode nxhtd manual
or to enable the automatic restart of the service:
$ sudo /etc/NX/nxserver --startmode nxhtd automatic

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

and:
StartHTTPDaemon Manual

Disabling the starting of the NoMachine HTTP server
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:

$ sudo /etc/NX/nxserver --restart

5.3. Using an Alternative Apache Web Server

NoMachine servers are designed to provide a fully integrated service to deploy sessions on the web which don'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. Look for detailed instructions in our Knowledge Base, section Articles, by searching for the 'Apache' keyword: https://kb.nomachine.com

5.4. Web Optimizations: Using WebRTC (Real-Time Web Communication)

The implementation of WebRTC support in browser-based remote desktop sessions has initially 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".

Specific articles can be found in the Knowledge Base, https://kb.nomachine.com.

6. Compression Techniques and Optimizations

---

This section describes how content of the remote screen is encoded in case of web sessions and client sessions and provides some hints for possible optimizations.

6.1. Video Stream Encoding in Web Sessions

In the case of web sessions, by default, session data is streamed in video frames compressed and decompressed by using the MJPEG lossy algorithm, which is the video-format widely supported by browsers.

Oher video codecs like VP8 and H.264, require a browser which supports WebRTC and HTML5.

NoMachine web sessions use H.264 video streaming when the following requirements are all met, otherwise VP8 is used.

1. WebRTC is enabled.
2. The browser supports WebRTC and the H.264 decoding

In practice, when WebRTC is enabled, H.264 or VP8 encoding will be used (if the browser supports WebRTC), otherwise the classic web media exchange protocol will be used and MJPEG will be the codec.

H.264 hardware encoding is possible when the Enterprise Terminal Server host machine has an hardware accelerated video card (GPU) with Nvidia Kepler microarchitecture onward or Intel Quick Sync processors.
Enabling HW acceleration by Quick Sync requires a manual configuration however, as explained here: https://www.nomachine.com/AR09O00938

Optimizations
Optimizations can be done in two ways: (I) by adjusting display settings in the session or (II) by enabling WebRTC.

1. Adjusting display settings in the web sessions
   To access NoMachine display settings, open the NoMachine menu inside the web session: press ctrl+alt+0 or click on the page peel in the upper right corner of the window to open it. Then click on the 'Display' button and finally on 'Display settings'. From this panel you can do the following.
   
   Change the display image quality
   Increasing the quality will mean to apply a minor compression ratio, the image will be clearer, but more bandwidth will be used.
   
   Disable network-adaptive display quality
   This will anchor the display quality to the fixed value specified in the Display quality slider, making it independent from the current network congestion. This is not recommended when there is a very limited bandwidth.
   
   Disable multi-pass display encoding
   Default settings within the encoding will work to refine the image progressively to the target quality (as specified in the Display quality slider) starting from a lower quality version of the image during moments of inactivity of the desktop. Disabling this refinement sends the image directly with target quality. Not recommended when there is limited bandwidth.
   
2. Enabling WebRTC
   NoMachine web sessions use by default the classic web media exchange protocol for two-way browser/web server communication. WebRTC (Real-Time Web Communication) is also supported and can be enabled as explained in the next paragraph.
   Enabling WebRTC allows to use the H.264 video streaming (when possible) or VP8 which optimize the user experience with multimedia applications and content.

You may verify which encoding method is in use from the NoMachine menu inside the session: press ctrl+alt+0 or click on the page peel in the upper right corner of the window to open it. Then click on the 'Display' button and finally on 'Display settings'. The codec actually in use is reported at the bottom left of the menu.

6.2. Video Streaming Encoding in Client Sessions

Sessions run by NoMachine client use a combination of video and image encoding based on standard codecs and a number of techniques developed by NoMachine. Frames are encoded into a video stream optimized by means of a compression and decompression algorithm of real-time image and audio data. VP8, H.264 and MJPEG encoding are supported.

In general, VP8 and H.264 are suitable for all situations, while MJPEG can be an alternative when the end-user's computer is less powerful and the user is experiencing slow responsiveness.

The display encoder can be changed on the server:

from the User Interface
In the Settings -> Server -> Performance panel, select 'Use a specific display encoding' and choose it from the list.

or in the node configuration file
Enable the use of a specific codec by editing the node configuration file and enabling the following two keys:
EnableDisplayServerVideoCodec 1
DisplayServerVideoCodec CODEC

where CODEC can be: 'vp8','h264' or 'mjpeg'. For example:
EnableDisplayServerVideoCodec 1
DisplayServerVideoCodec mjpeg

6.3. The X11 Vector Graphics Mode in Client Sessions

The X11 vector graphics mode is enabled by default for (i) virtual desktops and (ii) custom sessions in floating window mode. This mode is mainly a set of NoMachine techniques to compress and optimize the X11 protocol (by applying the same algorithms available with the NX compression protocol v. 3). These compression techniques are applied to all non-video content like textual elements, while multimedia content is encoded in a video stream (VP8 or H.264).

The X11 vector graphics mode is useful for avoiding loss of image quality and in general is the best option when working with traditional User Interfaces or a large amount of text. However it's not advisable for multimedia content or applications with many graphical effects.

This mode can also help to reduce bandwidth usage, decrease the HW requirements on client and server (expensive video encoding/decoding operations are applied only to multimedia content), and increase responsiveness on slow link and end-users' clients without hardware accelerated video encoding/decoding capabilities.

You can disable/enable the X11 vector graphics mode
via the User Interface
in the Server -> Settings -> Performance panel by selecting or not the 'Use X11 vector graphics mode in virtual sessions' option.

or in the node configuration file
Edit the node configuration file, uncomment and set the AgentX11VectorGraphics key to '0' for disabling the the X11 vector graphics mode:
AgentX11VectorGraphics 0

or to enable it:
AgentX11VectorGraphics 1

In the case of slow bandwidth, decreasing the quality level of images could help but if you need to have a perfect image without loss of quality, you should increase the display quality instead. It's also suggested to disable multi-pass encoding to avoid the 'out of focus' effect: multi-pass is an encoding technique which uses multiple passes to progressively reach the best definition of the image.

Quality level and multi-pass encoding can be tuned from the NoMachine menu inside the session in the Display -> Change settings panel. (Ctrl+alt+0 or click on the right upper corner of the window to open the NoMachine menu).

6.4. Supporting OpenGL Applications in Virtual Sessions

In NoMachine virtual desktops and custom sessions, OpenGL rendering is done by default by software components. This means that rendering tasks are accomplished by CPU and not offloaded onto the GPU. Such operations can be resource-intensive, especially in the case of 3D desktop graphics effects, and make the user interface look slow.

A possible alternative is to configure the NoMachine server to use the VirtualGL libraries (included in the NoMachine package) and therefore enable support for HW accelerated OpenGL applications. This allows OpenGL applications, namely 3D applications, to use server side graphics hardware.

In order to activate support for VirtualGL, follow instructions at https://kb.nomachine.com/AR05P00982.

7. Server Configuration

---

7.1. Configuration Files

The configuration file for the nxserver and nxweplayer/nxwebrunner programs is server.cfg. The configuration file for the nxnode program is node.cfg.

They are placed in (default installation):
/usr/NX/etc/server.cfg
/usr/NX/etc/node.cfg

The Default Configuration
NoMachine servers come with a default configuration that grants a working setup for the majority of environments. NoMachine administrators can tune their installation at any moment and according to their specific needs by setting the related configuration keys. In some cases this will require to restart all NoMachine services.

Edit the Configuration Files
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, e.g. 'vi'.

Be sure to uncomment the configuration key (i.e., remove the '#' pre-pended to the key) to set a different value to 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
Changes will be effective with the next new virtual desktop or custom session without the need to restart the server if not otherwise specified.

8. Services Management

---

Installation and upgrade procedures take care of configuring and starting all the necessary services to make the server ready to accept and serve user's requests for virtual desktops and custom sessions. The necessary services are configured to be restarted at each reboot of the host machine.

8.1. Disabling Access to the Desktop ('Desktop shared/Desktop not shared')

When you are sitting in front of the computer where the server is installed or you're connected there by NoMachine, you can switch off/on the ability to accept connections to the physical desktop via NoMachine by toggling 'Desktop shared/Desktop not shared'.

You can configure this setting via the NoMachine Monitor menu (right click on the !M icon in the system tray to open it). By selecting 'Desktop not shared', nobody can connect.

This setting lasts until you change it again, even when you physically log out from the system.

See also this tutorial for more details: https://www.nomachine.com/disabling-access-to-your-local-desktop

Once the current session is closed, by default only the owner of the desktop can connect again to the desktop when it's not shared. This behaviour is ruled by the ScreenSharingOwnerAccess key in server.cfg. Disable it to restore behaviour of v. 7 so that also the desktop owner will be no longer able to connect again:
ScreenSharingOwnerAccess 0
Be sure to remove the pre-pending # from the key name.

You can recover the ability to connect via NoMachine by changing settings in the Monitor menu on the physical computer.

It's possible to hide the 'Desktop shared/Desktop not shared' items from the !M menu by configuring the NoMachine node.cfg file on that computer and setting:
EnableAcceptingConnections 0
Be sure to remove the pre-pending # from the key name.

8.2. Stopping and Starting Server (nxserver) and Services

All NoMachine services can be stopped via:

the User Interface
all NoMachine services can be stopped by the Settings -> Server -> Server status panel ('Shut down the server'). When doing so, you will be asked if services must be started at the next reboot or not. You can restart services also from the Server status User Interface ('Restart the server').

or from command line.

Stopping all the NoMachine services

$ sudo /etc/NX/nxserver --shutdown
This will completely disable access to the server host machine and  terminate all sessions running on that host. By default, all  services will be restarted when the machine is booted. To override this  behavior, specify the --start-mode option when stopping the services:
$ sudo /etc/NX/nxserver --shutdown --start-mode manual

Starting NoMachine server and services

$ sudo /etc/NX/nxserver --startup
All services will be restarted at the next reboot. To not start services when the machine is rebooted, specify the start mode while running the --startup command:
$ sudo /etc/NX/nxserver --startup --start-mode manual

Specifying the start mode
It's possible to set the 'start mode' (if services will be started automatically at boot or not) by using:

$ sudo /etc/NX/nxserver --startmode manual
or:
$ sudo /etc/NX/nxserver --startmode automatic

Stopping and restarting NoMachine server and services

$ sudo /etc/NX/nxserver --restart

8.3. Stopping and Starting nxd and nxhtd

These are the NoMachine services listening for connections:

Program	Default port	Scope
nxd	4000	Accept connections by NX protocol
nxhtd	4443	Accept connections by HTTPS protocol (connections by the web)

You can stop a single service:

via the User Interface
in the Settings -> Server -> Ports panel. You can also choose the start mode: whether the service has to be started automatically at the next boot or not.

or from command line.

Stopping a service

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

where SERVICE can be:
nxd, the Network Server for accepting connections by NX protocol
nxhtd, the NoMachine web server for web sessions

Starting or restarting a service

$ sudo /etc/NX/nxserver --start nxd
$ sudo /etc/NX/nxserver --start nxhtd
or:
$ sudo /etc/NX/nxserver --restart nxd
$ sudo /etc/NX/nxserver --restart nxhtd

Specifying the start mode
By default each service is automatically restarted at the next boot. You can configure that on a per-service basis by running:

$ sudo /etc/NX/nxserver --startmode SERVICE manual
or to restore the default behavior:
$ sudo /etc/NX/nxserver --startmode SERVICE automatic

The commands above operate on the configuration keys listed below. You can change them manually in the server configuration.

Configuration	Key setting
Enable automatic starting of the NX Network server, nxd	StartNXDaemon Automatic
Disable automatic starting of the NX Network server, nxd	StartNXDaemon Manual
Enable automatic starting of the NoMachine web server, nxhtd	StartHTTPDaemon Automatic
Disable automatic starting of the NoMachine web server, nxhtd	StartHTTPDaemon Manual

8.4. Local and Network Ports

For each session, NoMachine uses ports that are used only locally on the server host and network ports.

Some ports are mandatory and must be available, e.g. the session display number and the connection port. Other ports are used for services that can be disabled (e.g. USB forwarding, UDP communication).

Local port	Description	How to change the default
11000 + DisplayBase	Session display. If this port is already in use, NoMachine will look for a free port by incrementing DisplayBase up to the value set in the DisplayLimit server configuration key.	DisplayBase (by default 1001) and DisplayLimit (200) are defined in server.cfg
20000	Communication port between the session's nxserver process and the main server process.	Add the ServerSlaveBase key to the end of server.cfg and specify a value
24000 + DisplayBase	Session's monitor port.	DisplayBase (by default 1001) and DisplayLimit (200) are defined in server.cfg
5473 and 5483	USB devices forwarding.	Disable USB sharing by setting EnableUSBSharing none in node.cfg

Network port	Description	How to change the default
6000 + DisplayBase	TCP port for the NoMachine display service. If this port is already in use, NoMachine will look for a free port by incrementing DisplayBase up to the value set in the DisplayLimit server configuration key.	DisplayBase (by default 1001) and DisplayLimit (200) are defined in server.cfg.
5353	UDP port for the MDNS service to broadcast computer's information over the LAN.	Disable the service by setting EnableLocalNetworkBroadcast 0 in server.cfg.
4000	TCP port for the NoMachine Network service (nxd) and connections via NX protocol. This port must be open in the firewall and mapped to the external IP of the server host.	Set NXTCPPort in server.cfg and restart the nxd service.
4000	Port for UDP communication for connections via NX protocol.	Set NXUDPPort in server.cfg and restart the nxd service. It can be changed also in the server administration UI.
22	TCP port for connections via SSH protocol. This port must be open in the firewall and mapped to the external IP of the server host.	Set a different port for the system SSH server and align value set for SSHPort in server.cfg. Then restart the NoMachine server.
4443	HTTPS port for web connections. This port must be open in the firewall and mapped to the external IP of the server host.	See https://www.nomachine.com/AR07S01137
20000 - 30000	External ports range for UPnP port mapping.	Set NXTCPUPnPPort in server.cfg to define a different range. Set EnableUPnP none in server.cfg to disable port mapping.
5040 + x	Port opened between client and server for each USB device. Port number is defined by 5040 + x where 'x' is the first free port retrieved starting from port number 5040.	N/A
4000	Automatic updates from NoMachine repositories.	Updates are managed by nxd. Disable automatic updates by setting UpdateFrequency 0 in server.cfg.
5473 and 5483	USB devices forwarding.	Disable USB sharing by setting EnableUSBSharing none in node.cfg.

8.5. Hiding Server Settings or the !M Icon from the System Tray

It is possible to hide or show the 'Show server status' item displayed in the !M (the Monitor) menu in the system tray.

This can be done by setting in the node configuration:
EnableServerStatus 0

Then restart NoMachine server, via UI or from command line:

$ sudo /etc/NX/nxserver --restart

It's also possible to hide the possibility to access server settings via UI. Edit the node.cfg file and set:
EnableServerPreferences 0

It's not necessary to restart the server, but if you have already the NoMachine UI open, close and re-open it to make changes effective.

To hide settings for the Server in the UI, set both EnableServerStatus 0 and EnableServerPreferences 0. If you have the client UI (main window and/or session window open), close and reopen it to make changes effective.

It is possible to hide or show the !M (the Monitor) icon of the server in the system tray. When the icon is hidden, notification messages will still be displayed when users are connecting.

This can be configured in the node configuration file.

To hide the !M in the system tray set:
DisplayMonitorIcon 0

To display the !M in the system tray set:
DisplayMonitorIcon 1

In both cases, then restart the server, via UI or from command line as described above.

8.6. Hiding the Whiteboard and Chat Tools

If you want to disable the Whiteboard from the Monitor menu, edit the node configuration file to have:
EnableWhiteboard 0

Then restart the server:

$ sudo /etc/NX/nxserver --restart

8.7. Discovering this Server on LAN

By default NoMachine servers broadcast information to let other NoMachine computers to discover them on the local network. You can disable this feature via:
the User Interface
In the Settings -> Server > Ports panel, uncheck 'Advertise this computer on the local network'.

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

Then restart the server to make changes effective:

$ sudo /etc/NX/nxserver --restart

9. Notifications to Users

---

This section explains how to use the NoMachine whiteboard to exchange messages with the connected users or the server tools to notify users for example about incoming maintenance operations.

9.1. Whiteboard and Custom Notifications

NoMachine provides an instant messaging tool, named whiteboard which also allows drawing, the sharing of files with connected users and fast-track access to file transfer. To access it, connect to the user's desktop and from the Monitor (!M icon) in the system tray click on 'Show the whiteboard'. Note that if multiple users are connected at the same time to the same session, they will all see the same message.

As an alternative, it's possible to issue a dialog in the connected sessions to show a custom message by sending it from command line.

Sending a message:

to all running sessions:
$ sudo /etc/NX/nxserver --broadcast "Your message goes here"
or sending a message only to the session specified by its session id:
$ sudo /etc/NX/nxserver --message  SESSION_ID  "Your message goes here"

9.2. Greeting Messages (for Virtual Desktops)

It is possible to welcome users when the virtual desktop has started by issuing a greeting message, either only the first time the user logs-in or every time the user connects to the Enterprise Terminal Server. Update the node configuration file by writing the text of your message in any of the following keys:
NodeFirstLoginGreeting "Welcome to your first NX session"
NodeLoginGreeting "Welcome to your NoMachine session"

10. Supported Connection Protocols and Authentication Methods

---

NX Protocol
connections by default use the NX protocol which is its own protocol for secure communication over the network. Encryption in the NX protocol is implemented using OpenSSL TLS/SSL, based on ECDHE-RSA-AES128-GCM-SHA256 as the default cipher suite. ECDHE-RSA-AES128-GCM-SHA256 is an AES (Advanced Encryption Standard) block cipher with 128 bits key in GCM (Galois/Counter Mode). RC4 (ECDHE-RSA-RC4-SHA cipher suite) is used as backward compatibility when connecting from or to versions 4.0.

When using the NX protocol, NX data can travel on TCP and UDP streams, even at the same time. The client and server can decide dynamically what transport to use, based on the type of data and the network conditions. Client and server negotiate the UDP transport at session startup, after having negotiated the main TCP link. UDP uses symmetric Blowfish encryption, with key negotiated on the secure TCP link. UDP is presently not available when using SSH tunneling to ensure that all data goes through the same SSH link, as it was in legacy version 3. UDP protocol can be also disabled.

SSH Protocol
NoMachine Enterprise Terminal Server also provides tunneling of connections using SSH and full integration with any authentication backend supported by the host SSH server.

Authentication methods
These are the authentication methods supported by NoMachine when connections use the NX protocol or the SSH protocol:

Authentication method	NX protocol	SSH protocol
Login with user's password	yes	yes
Login with SSH private key	yes	yes
Login with SSH private key provided by SSH agent (available since v. 6.3.6)	-	yes
Login with SSH private key private key stored on a PKCS11 smart card	-	yes
Login with Kerberos ticket	yes	yes
Support for SSH agent forwarding	-	yes
Support for Kerberos tickets authentication forwarding	yes	yes
Support for two-factor authentication	yes	yes

10.1. Defining Protocol in Server Configuration

Protocols are defined in the ClientConnectionMethods key in the server configuration. They are specified as a comma-separated list of values:
ClientConnectionMethods NX,SSH,HTTPS

This key is automatically populated during the installation or the update of the package. It is possible to exclude any of the available protocols to force users to connect by the desired protocol.

For example, to use only NX protocol, set this key to:
ClientConnectionMethods NX

and restart the server to make changes effective:

$ sudo /etc/NX/nxserver --restart

If your server supports SSH but it still reports that SSH is not available, check the ClientConnectionMethods key and ensure that the SSH values is set. Then restart the server.

Removing 'HTTPS' from the ClientConnectionMethods key will disable the starting of the NoMachine HTTP server and prevent connections via web.

10.2. Locking Down the Accepted Authentication Methods

Administrators may decide how the user should authenticate on the server by defining which authentication method(s) is/are available. Authentication methods can be set in the server configuration file by editing this key:
AcceptedAuthenticationMethods all

By default all methods are accepted. They can be restricted by providing a comma-separated list of values, they will indicate which authentication method is permitted.

Accepted values for connections by NX protocol are:
NX-password to allow password authentication.
NX-private-key to allow key-based authentication.
NX-kerberos to allow Kerberos ticket-based authentication.

while for connections by SSH protocol:
SSH-system to allow all methods supported for the system login. SSH authentication methods for the system login have to be set on the system for example in the PAM configuration.

For example, to accept key-based and Kerberos ticket-based authentication for the NX protocol:
AcceptedAuthenticationMethods NX-private-key, NX-kerberos

Settings in the client UI
When you connect by the client to a remote computer, you can select the authentication method for your connection while creating it or change it later (right mouse click on the connection icon -> Edit connection -> Configuration).

10.3. Changing Port for the NX Protocol

The default setting of NoMachine is to run connections via the NX protocol on port 4000. On the server side, nxd is listening on port 4000. It's mandatory that this port is open between client and server to allow connections by NX protocol.

If you change the port for nxd, connecting users will have to specify the new value in their connection settings in the client User Interface.

It's possible to modify the port for nxd
from the User Interface
in the Settings -> Server -> Ports panel.

or in the server configuration file by editing this key:
NXTCPPort 4000

Restarting the nxd service is necessary to make this change effective:

$ sudo /etc/NX/nxserver --restart nxd

When NX protocol is used, UDP communication for multimedia is enabled by default. UDP traffic uses a range of ports between 4011 and 4999. These ports must be open between client and server. If they are not available, traffic will fall back to TCP communication. You can change the port range, define a comma-separated list of ports or a single port by changing value set for the following key in the server configuration:
UDPPort 4011-4999

10.4. Changing Port for the SSH Protocol

The default port used for the SSH protocol is 22 on Linux. On such platform NoMachine relies on the SSH server installed on the system. If your SSHD is configured to listen on a port different from 22 you need to align the NoMachine server configuration accordingly. Connecting users will have to specify such value in their connection settings in the player User Interface.

If your SSH server is listening on a port different than 22, change the SSH port via UI in the Settings -> Server -> Ports panel

or in the server configuration file by editing this key:
SSHPort 22

10.5. Connecting to a Server Behind a Firewall (UPnP Port Mapping)

Automatic discover of the NoMachine server host is possible only when the server and the user's machine are on the same LAN. When the user connects over the internet or from a different network, it's mandatory to know the public (or external) IP of the NoMachine server .

When the server is behind a firewall, you have to configure the router to forward the external port to the nxd service (to use the NX connection protocol), to the SSH server (to use the SSH protocol) and to the nxhtd service (to connect via web). By default the required ports are TCP ports: 4000 for NX, 4443 for HTTPS and UDP ports in the 4011-4999 range. Note that users will have to specify the external port in their connection settings in the player User Interface.

If the router on the server side supports UPnP/NAT-PMP, you can let NoMachine try to enable port forwarding in the router automatically. External ports will be selected randomly from the 20000 - 30000 range. Also in this case users will have to specify the external port in their connection settings in the player User Interface.

For connections by NX protocol, at session startup NoMachine will also try to map UDP ports by using UPnP.

Enabling the automatic port forwarding
Step 1: Set in the server configuration:
EnableFirewallConfiguration 1

Step 2: Specify for which service the port forwarding must be enabled by listing them in the following key:
EnableUPnP NXTCP,NXUDP,SSH,HTTP

Step 3: (optional) Specify the port where the NX service will be redirected by editing respectively:
NXTCPUPnPPort ""; SSHUPnPPort "" and HTTPUPnPPort ""

To allow only connections by SSH (on external port 20048 for example) and use the automatic port forwarding, set in the server configuration:
ClientConnectionMethods SSH
EnableFirewallConfiguration 1
EnableUPnP SSH
SSHUPnPPort "20048"
and restart the server.

You can enable port forwarding for connections by NX and HTTP/HTTPS protocol also from the User Interface via the Settings -> Server -> Ports panel by selecting the service and enter its settings (click on 'Configure'). Then check the Gateway port option.

Retrieving information about UPnP port mapping and manual port mapping
When the automatic port mapping is enabled, you can retrieve information about UPnP port mapping, e.g. IP of the gateway device, external port and port mapped. You can also start and stop the port mapping via command line. Execute any of the following commands in a terminal:

$ sudo /etc/NX/nxserver --upnpstatus
To terminate port mapping:
$ sudo /etc/NX/nxserver --upnpunmap
To initiate port mapping:
$ sudo /etc/NX/nxserver --upnpmap
You can also specify for how long port mapping should last by using
$ sudo /etc/NX/nxserver --upnpmap --time 

10.6. Using NoMachine DBs for Managing User Access

Use of NoMachine DBs can be configured by editing the server configuration. The table below reports which configuration key value has to be set to enable or disable specific behavior as defined in the 'Target' field:

Target	Server configuration key	Description
User's access based on system authentication (default)	EnablePasswordDB 0	Authentication is requested to the system, user's connection is allowed once the user has been authenticated. PAM, LDAP, AD are supported.
User access based on NX Password db	EnablePasswordDB 1	Authentication is verified against the NX password DB. Separate the NoMachine authentication from the system authentication. The user's account must exist on the system.
Allow connections from all authenticated users (default)	EnableUserDB 0	Every time a new account is created via NoMachine or an already existing system user runs the session for the first time, the user is added to the NoMachine NX Users DB, even when the use of NX Users DB is disabled. These users cannot be disabled and are always allowed to connect if they authenticate successfully.
Enable or disable user's access to NoMachine	EnableUserDB 1	By default all users are enabled to access the NoMachine system once authenticated. With this configuration a user can be disabled and re-enabled at any moment from command line.

10.7. Redirecting Connections to Another Server

Redirection from Server A to Server B may be triggered on the client IP address (or hostname)  or on the username.

If based on client IP or hostname, redirection can be made before the user has authenticated on the Server A host machine. If based on username instead, redirection will always be done after the user has authenticated on host machine A. Note that when redirection occurs after user authentication, once the client is redirected, the user will be requested to provide their credentials to authenticate on the Server B host machine.

Redirect clients on a per-IP basis

To create the list of clients to be redirected on their IP-basis, execute for each client:

$ sudo /etc/NX/nxserver --hostadd CLIENT_IP --redirect SERVER_IP:PORT

Port is the nxd listen port when the user connects by NX protocol (by default 4000) or the SSH listen port (22 on Linux and macOS; 4022 on Windows).

It's possible to specify a single IP or a family IP. Multiple directives to redirect the same client IPs or hostnames to different servers are disallowed. For example, the following directives are not allowed:
Client IP          Redirected to
192.168.1.1     server B
192.168.1.1      server C

The following directives, instead, are accepted:
Client IP         Redirected to
192.168.1.1     server B
192.168.1.*     server C
192.168.*.*     server D

The star wildcard can also be used when specifying hostnames. For example: *.nomachine.com.

Note that when the client is connecting, the server is aware of its client IP only. In order to retrieve its hostname, the server has to make a reverse DNS lookup. This operation, depending on the system configuration, could slow down the session start-up procedure. For this reason, it is strongly suggested to specify client IP(s) when setting a redirect directive, expecially if the redirect has to be applied before the user has authenticated on the NX Server A host machine.

To modify parameters set for redirection of that client:

$ sudo /etc/NX/nxserver  --hostedit CLIENT_IP SERVER_IP:PORT

To list all redirections set for clients:

$ sudo /etc/NX/nxserver  --hostlist  

or for a specific client only:

$ sudo /etc/NX/nxserver  --hostlist  CLIENT_IP  

To delete the redirection for that client:

$ sudo /etc/NX/nxserver  --hostdel CLIENT_IP  

Redirect clients on a per-username basis

Redirection on a per-user basis is always done once the user is logged to Server A.

To add redirect connections made by an existing user:

$ sudo /etc/NX/nxserver  --useradd USER --redirect SERVER_IP:PORT

Port is the nxd listen port when the user connects by NX protocol (by default 4000) or the SSH listen port (22 on Linux and macOS, 4022 on Windows).

To create the user's account on the system, and redirect his/her connections, add the '--system' command to the previous command:

$ sudo /etc/NX/nxserver --useradd USER --system --redirect SERVER_IP:PORT

To edit the redirection settings:

$ sudo /etc/NX/nxserver  --useredit USER --redirect SERVER_IP:PORT

To remove the redirection:

$ sudo /etc/NX/nxserver  --useredit USER --redirect none

11. Local Users 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 server, even without the need of the owner's approval.

11.1. Managing Local System Accounts on the Server Host

To be able to login to the Enterprise Terminal Server host, you need to have a valid account on that host and the password cannot be empty. Your account can be a local account or a LDAP account or an AD account. NoMachine doesn't check if the source of users' account information is for example LDAP or local account database. Be sure to configure the login in advance.

You can create a local account by means of system tools, or via command line by using the 'nxserver' commands:

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

Separate the system login from the NoMachine login
You can assign a password, specific for the NoMachine login only, different from system password to any valid account. To do that, enable NoMachine Password DB (EnablePasswordDB 1) in server.cfg and ensure that the user is added to the NoMachine backend:

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

Enabling and Disabling access for a NoMachine User
Prerequisites are:

i) The user has been added to NoMachine DBs by means of 'nxserver --useradd USERNAME' command.

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

You can enable/disable a user and allow/forbid access to the Enterprise Terminal Server for that user by running:

$ sudo /etc/NX/nxserver --userenable USERNAME
or:
$ sudo /etc/NX/nxserver --userdisable USERNAME
Note that 'nxserver --useradd USERNAME' adds the user to NoMachine DBs and automatically enables the user to log-in, while 'nxserver --userdel USERNAME' removes the user from NoMachine DBs and disables the user's ability to login by NoMachine.

Modifying the User's Password
You can modify the user's system password by running:

$ sudo /etc/NX/nxserver --passwd USERNAME --system
or you can modify just the NoMachine password when Password DB is in use( EnablePasswordDB 1 is set in server.cfg):
$ sudo /etc/NX/nxserver --passwd 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. You can retrieve the complete list by running:

$ sudo /etc/NX/nxserver --userlist

11.2. Connecting with a Privileged System Account

By default, NoMachine allows the running of sessions as privileged system user ('root' or 'sudo' on Linux). You can however configure the NoMachine Server to disallow it. Do it by disabling the following server configuration key:
EnableAdministratorLogin 0

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

11.3. NoMachine Trusted User and Administrators

A NoMachine Trusted is an user who can connect to a virtual and/or physical desktop of another user without the need of the explicit approval of the desktop owner.

A NoMachine Administrator is an user with some additional privileges for NoMachine, like the ability to add nodes or connect to the remote desktop without the need of being authorized by the desktop owner.

Make users trusted for connecting to virtual desktops of other users

To create a new user on the system, trusted for NoMachine virtual desktops:

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

To make an existing user trusted:

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

To make a user trusted for specific users' desktops
You can assign the 'trusted' flag and make the user trusted only for those desktops owned by a specific user or list of users. For example, if a new user (userB) should be created on the system and made trusted only for desktops of userA:

$ sudo /etc/NX/nxserver --useradd userB --system --trusted virtual --per-user userA

It's also possible to specify more users in a comma-separated list, e.g.:
$ sudo /etc/NX/nxserver --useradd userB --system --trusted virtual --per-user userA,userC,userD

To remove trusted permissions:

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

To list only trusted users:

$ sudo /etc/NX/nxserver --userlist --trusted

Make users trusted for connecting to the physical desktop

To create a new trusted user for connections to the physical desktop:
In a similar way, you can create a new user trusted for connections to the physical desktop only, or make an existent user trusted for them:

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

To remove trusted permissions:

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

To list only trusted users:

$ sudo /etc/NX/nxserver --userlist --trusted

To make a user trusted for both NoMachine virtual desktops and connections to the physical desktop, do not specify the 'virtual' or 'physical' attribute, i.e.:

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

Make users NoMachine administrators

Being a NoMachine administrator doesn't alter current system privileges for that user.

To make an existing user NoMachine administrator:

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

To remove NoMachine administrator's privileges:

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

11.4. Managing Groups of Users

Two kind of groups of users are supported: system groups and NoMachine groups with the possibility to set attributes (e.g. the trusted flag) to the group or create profiles rules which apply to all users belonging to the given group (e.g. disable the possibility to print and share disk).

System groups have to be managed (created,configured,deleted etc ...) by system tools. NoMachine groups are completely separated from system groups and have to be managed via nxserver.

Using NoMachine groups of users
Create the NoMachine group:

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

Add an existent user to the NoMachine group:

$ sudo /etc/NX/nxserver --useradd USERNAME --group GROUP

Change the group for a given user:

$ sudo /etc/NX/nxserver --useredit USERNAME --group GROUP

Remove the user from the group:

$ sudo /etc/NX/nxserver --userdel USERNAME --group GROUP

Delete a group, if there are not profile rules associated to the group:

$ sudo /etc/NX/nxserver --groupdel GROUP

List all groups:

$ sudo /etc/NX/nxserver --grouplist

Some practical examples
These examples applies also to a system group of users.

Make all users of a group 'trusted' for connections to virtual desktops:

$ sudo /etc/NX/nxserver --groupedit GROUP --trusted virtual

Make all users of a group 'trusted' for connections to physical desktop:

$ sudo /etc/NX/nxserver --groupedit GROUP --trusted physical

Use 'nxserver --groupedit GROUP --trusted' to make the group trusted for both connections to virtual and physical desktops.

Remove the trusted flag:

$ sudo /etc/NX/nxserver --groupedit GROUP  --trusted none

Make the group trusted for specific users' desktops
You can assign the 'trusted' flag and make the group (and all users belonging to that group) trusted only for those desktops owned by a specific user or list of users. For example, if a new group (groupB) should be created and made trusted only for desktop of userA:

$ sudo /etc/NX/nxserver --useradd userB --system --trusted virtual --per-user userA
It's also possible to specify more users in a comma-separated list, e.g.:
$ sudo /etc/NX/nxserver --useradd userB --system --trusted virtual --per-user userA,userC,userD

11.5. Using Virtual Desktop Guests (System Guest Users Accounts)

The automatic generation of guest accounts is not enabled by default. It can be enabled via UI: in the Settings -> Server -> Security panel, check the 'Allow guest users to create new virtual desktops' option.

Otherwise, edit the server.cfg file on the server host and set:
EnableGuestCreateVirtualDesktop 1

System guest users 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.

12. Session Management

---

Each session on the same server is uniquely identified by a session id (which can look like: B253864E822F5A235825F3AB8853AF00) and a display id (e.g. 1002).

A session on the NoMachine Enterprise Terminal Server can be in any of the following statuses:
Connected - when it's connected to the remote display.
Disconnected - this status is available only for virtual desktop sessions and custom sessions. A session is marked as disconnected when it's disconnected from the remote display. A disconnected session can be reconnected at any time even from a different machine (migration). While a session is disconnected, applications on the remote server stay running. Finished - the session has been closed in a clean way and all NoMachine processes have been shut-down smoothly.
Failed - any of the NoMachine processes has failed to start or it has been "un-cleanly" terminated.
Transitional statuses are Connecting, Disconnecting and Terminating.

The server is able to manage different types of sessions, named internally as in the table below. You can see the complete list of supported session types by running:

$ sudo /etc/NX/nxserver --resourcelist --class session

Session type	Description
physical-desktop	Connect to the physical desktop of the server host.
unix-xsession-default	Run the default desktop environment as set on the system in a NoMachine virtual desktop
shadow	Connect to a virtual desktop session (desktop sharing/collaboration).
unix-console	Run a virtual Unix console application. It can be embedded into the client session window or be a floating window console depending on the user's choice: run or not the custom session in a virtual desktop
unix-desktop	Run a virtual custom application embedded into the player session window.
unix-application	Run a virtual custom application. It can be embedded into the client session window or be a floating window application depending on the user's choice: run or not the command in a virtual desktop.
unix-gnome	Run a virtual GNOME desktop. The ConnectPolicy key in the server configuration must have 'desktop=1' set.
unix-kde	Run a virtual KDE desktop. The ConnectPolicy key in the server configuration must have 'desktop=1' set.
unix-xdm	Run a virtual desktop through the X Desktop Manager.
unix-default	Run a virtual session by using the default X client script on server.
unix-script	Run a virtual session by using the X client script on server as specified by path.

12.1. Monitoring Sessions

You can monitor sessions from command line tools. Below are the server commands to be run from xterm or console.

Listing Running Sessions
To list all the running sessions, their display, session owner, remote IP of the connected client, session ID and session host:

$ sudo /etc/NX/nxserver --list
You can also filter results on a per-user basis:
$ sudo /etc/NX/nxserver --list USERNAME
or gather further information about connected clients:
$ sudo /etc/NX/nxserver --list --client-version --client-platform

The number of active connections on the server corresponds to the number of sessions in status Connected. Session status is shown in the output of session history command.

Session History
History is preserved for a certain amount of time as set in the server configuration (SessionHistory key). To see the complete list of sessions, including those that have been cleanly terminated or failed, run:

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

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

Debugging a Failed Session with Session History
If a session is marked as failed in the session history output, the following command should provide information about the reason of the failure. The output of the following commands provides a short report helpful for a preliminary debug of the problem:

$ sudo /etc/NX/nxserver --history SESSIONID
To redirect the error report to a file:
$ sudo /etc/NX/nxserver --history SESSIONID --file FILE

Retrieving Statistics about Sessions with Session History
This feature elaborates a number of information about sessions, contained in the current session history. For example the number of sessions started, terminated, running and failed and their average startup time. The command to retrieve statistics is:

$ sudo /etc/NX/nxserver --history --stats
To redirect statistics to a file:
$ sudo /etc/NX/nxserver --history --stats --file FILE

For Enterprise Terminal Servers
To retrieve history information for a node, specify it in the NODE:PORT format:

$  sudo /etc/NX/nxserver --history NODE:PORT

Clearing Sessions History
You can reset the history backlog by running the following command.

$ sudo /etc/NX/nxserver --history clear

Configuring the Session History Backlog
Data is preserved for 30 days. You can modify it in the server configuration file by uncommenting and setting a different value for the following key:
SessionHistory 2592000

This key accepts the following values:
< 0 Never delete data from NX session history.
0 Disable NX session history.
> 0 Keep data in session history for this amount of seconds.

12.2. Managing Sessions

Disconnecting a Virtual Desktop Session from Command Line
You can disconnect a session by running:

$ sudo /etc/NX/nxserver --disconnect SESSIONID
or:
$ sudo/etc/NX/nxserver --disconnect DISPLAYID
You can also disconnect all sessions belonging to a specific user:
$ sudo /etc/NX/nxserver --disconnect USERNAME

Take SESSIONID or DISPLAYID from the output of the 'nxserver --list' command, they are the 'Session ID' and 'Display' column respectively. The same output also shows the user's name.

Disconnecting or Terminating Virtual Desktops Automatically
To disconnect a virtual desktop or custom sessions after a certain time of inactivity, uncomment and set a proper timeout value, in seconds, in the following node configuration key. For example, if you want to terminate sessions after 10 minutes of inactivity you need to set:
DisplayServerExtraOptions "-timeout 600"

If the NoMachine display agent doesn't receive any input from the user in the given timeout, it will either disconnect or terminate the session. Termination of the session will be carried out if the session is not persistent or no X application is connected to the display. Otherwise the agent will disconnect the session so that the X applications will be left running.

Note that the DisplayServerExtraOptions key is only for virtual desktops or custom sessions with X11 vector graphics enabled (default).

For web sessions, sessions connected to a virtual desktop (sharing of the virtual desktop), virtual desktops with X11 vector graphics disabled and connections to the physical desktop, set instead:
DisplayAgentExtraOptions "-timeout 600"

Terminating the Session from Command Line
To terminate a virtual desktop or custom session:

$ sudo /etc/NX/nxserver  --terminate SESSIONID
or:
$ sudo /etc/NX/nxserver  --terminate DISPLAYID
You can also terminate all sessions belonging to a specific user:
$ sudo /etc/NX/nxserver --terminate USERNAME
If you want to terminate all sessions, just restart the server:
$ sudo /etc/NX/nxserver --restart
or if you want to terminate all sessions and forbid new connections until the server is started again:
$ sudo /etc/NX/nxserver --shutdown
To start the server after a shutdown:
$ sudo /etc/NX/nxserver --startup

Automatically Terminating Virtual Desktop/Custom Sessions in Status Disconnected
It's possible to specify for how long the server has to keep alive virtual desktops in the disconnected status. When the time has expired, the server will terminate virtual desktops if no user is connected there. To let the server terminate a disconnected virtual desktop after XXX seconds, edit the server configuration file, uncomment and set the timeout value (XXX) expressed in seconds in the following key:
DisconnectedSessionExpiry XXX

For example, by setting:
DisconnectedSessionExpiry 600
a virtual desktop will terminate after ten minutes provided there is no activity.

Automatically Terminating Virtual Desktop/Custom Sessions when the Maximum Number is Reached
To terminate a disconnected session when the maximum number of virtual desktops (see 'Limiting the Number of Virtual Desktops' below) is reached and make room for a new virtual desktop or custom session, enable the following key in the server.cfg file:
EnableAutokillSessions 1

Limiting the Number of Virtual Desktops or Custom sessions
You can set a limit for the number of virtual desktops provided so that the limit does not exceed the number of connections allowed by the server license value (it's the 'Virtual Desktops' field in the server.lic file). NoMachine Enterprise Terminal Server allows unlimited concurrent virtual desktops.

For example to configure the server to allow only two concurrent virtual desktops, edit the server configuration and set:
VirtualDesktopsLimit 2

You can also specify how many virtual desktops a single user may run. For example, to allow 1 connection per-user, uncomment and set the following key in the server configuration file:
VirtualDesktopsUserLimit 1

A Practical Example
Limit the number of virtual desktops to three and keep alive a virtual desktop (inactive & disconnected) for one day. If a new virtual desktop is requested, the server will terminate the oldest virtual desktop in status disconnected to make room for the new session.
VirtualDesktopsLimit 3
EnableAutokillSessions 1
DisconnectedSessionExpiry 86400

Automatic Disconnection of Users
The automatic disconnection is a server configuration to rule the server behavior when the limit of users is exceeded and a new user is requesting to connect.

Current options are:
disabled (0): this is the default. The server will issue a pop-up message before disconnecting the user. The current user can accept or not to disconnect itself. If no choice is made, the server will automatically disconnect this user and let the incoming user to connect.
enabled (1): the server will automatically disconnect the user to make room for the new user. No message is issued to the already connected user.
none (2): the server will prompt the connected user to accept or refuse to disconnect for making room for the incoming user. If no choice is made, the server doesn't disconnect the user and advise the incoming user that the maximum number of allowed connections is reached.
silent (3): the server never notifies desktop owners about incoming users, incoming users are informed that the maximum number of allowed connections is reached.

The automatic disconnection applies when the maximum number of available connections to the desktops or the maximum number of available virtual desktops is exceeded.

To enable the automatic disconnection set the following key in the server.cfg file:
AutomaticDisconnection 1

To let the connected user decide or refuse to disconnect, set:
AutomaticDisconnection 0

Disabling persistent virtual desktops
Users may be forced to terminate their virtual desktop session by setting in the server configuration:
DisablePersistentSession all

In this way when the user closes the virtual desktop, the session is terminated instead of being disconnected. This server configuration key also accepts a list of comma-separated usernames and will be applied to the specified users. Non-persistent sessions cannot be reconnected.

12.3. Using Any of the Available Desktop Environments

Pre-requisite to connect using NoMachine is that a desktop environment is installed on the system even if the host is headless or not started in graphics mode.

By default when the user chooses to create a new virtual desktop, NoMachine runs the default X session set on the system.

During its installation, NoMachine detects the default desktop environment set on the system and configures the node accordingly. Path and command to start the system desktop environment is defined in /usr/NX/etc/node.cfg by the DefaultDesktopCommand key. The Enterprise Terminal Server is able to detect GNOME, Unity, KDE, LXDE and Xfce. If you have a different desktop environment, you can edit the DefaultDesktopCommand key accordingly.

For example to run MATE:
DefaultDesktopCommand "/usr/bin/mate-session"

or to run Pantheon:
DefaultDesktopCommand "/usr/bin/gnome-session --session=pantheon"

If there are multiple desktop environments, you can configure NoMachine to provide users the list of all the available desktop types installed and configured on the system (i.e. available in /usr/share/xsessions).

To enable that, set 'xsessions=1' in the ConnectPolicy key in /usr/NX/etc/server.cfg:
ConnectPolicy autocreate=1,autoconnect=1,automigrate=1,desktop=0,dialog=0,xsessions=1,udp=1
Be sure to remove the pre-pending # from the key name.

If you want provide a choice between GNOME and KDE only, and/or if you want to provide XDMsessions, you can set:
ConnectPolicy autocreate=1,autoconnect=1,automigrate=1,desktop=1,dialog=0, xsessions=0,udp=1

To run GNOME and/or KDE, ensure that the appropriate command is set in the corresponding keys in node.cfg, for example
CommandStartGnome "/etc/X11/Xsession 'gnome-session --session=gnome'"
CommandStartKDE "/etc/X11/Xsession startkde"

To configure XDM sessions, read here: https://kb.nomachine.com/AR06Q01035

12.4. Activating the Disconnect/Terminate Dialog

Terminating a virtual desktop session is done at the system level of the Enterprise Terminal Server host. For example, if you are running a virtual desktop session (Gnome), you terminate the session by choosing the logout option from Gnome's system menu.

Disconnecting the session is done by clicking the 'X' button in the upper corner of the window. Alternatively, you can disconnect via the NoMachine session menu panel (Ctrl-Alt-0 -> Connection -> Disconnect).

It's possible to display a dialog to let the user decide whether to disconnect or terminate the virtual desktop session when clicking on the X button which closes the session window.

The Disconnect/Terminate dialog is available for:

1. virtual desktops running in X11 vector graphics mode
2. virtual desktops not running in X11 vector graphics mode
3. virtual custom sessions

To enable the Disconnect/Terminate dialog, enable the 'dialog' option (i.e. set dialog=1) in the following key in server.cfg:
ConnectPolicy autocreate=1,autoconnect=1,automigrate=1,desktop=0,dialog=1,xsessions=0,udp=1

12.5. Server Automation Interface: Custom Scripts executed on Server/Node Events

The server configuration provides a number of keys that can be activated to execute a custom script upon a certain event. According to the event, a number of parameters can be specified for each script. In a similar way, a number of keys is present in the node configuration file to allow to execute a custom script on a certain NoMachine node event. In both cases and according to the event, a number of parameters can be specified for each script. Value of parameters are listed in a positional order and corresponds to $1,$2,$3 etc … For example, a basic script on Linux to be executed in UserScriptAfterLogin key allows to retrieve
the name of the user who is logged (username) and the IP of his/her machine (remote IP):

#!/bin/sh
username=$1
remoteIP=$2
echo "$username $remoteIP"  >> /tmp/UserScriptOutput.log

Available for	Configuration key	Parameter $1,$2 etc ... (server.cfg)	Parameter $1,$2 etc ...(node.cfg)
server	UserScriptBeforeLogin	remote ip	-
server	UserScriptAfterLogin	username, remote ip	-
server	UserScriptAfterLogout	username, remote ip	-
server,node	UserScriptBeforeSessionStart	session id, username, node host, node port, main session id(*), main session type(*)	session id, username, session type, display, main session id(*), main session type(*)
server,node	UserScriptAfterSessionStart	session id, username, node host, node port, main session id(*), main session type(*)	session id, username, session type, display, main session id(*), main session type(*)
server,node	UserScriptBeforeSessionDisconnect	session id, username, node host, node port	session id, username, session type, display
server,node	UserScriptAfterSessionDisconnect	session id, username, node host, node port	session id, username, session type, display
server,node	UserScriptBeforeSessionClose	session id, username, node host, node port, main session id(*), main session type(*)	session id, username, session type, display, main session id(*), main session type(*)
server,node	UserScriptAfterSessionClose	session id, username, node host, node port, main session id(*), main session type(*)	session id, username, session type, display, main session id(*), main session type(*)
server,node	UserScriptBeforeSessionReconnect	session id, username, node host, node port	session id, username, session type, display
server,node	UserScriptAfterSessionReconnect	session id, username, node host, node port	ssession id, username, session type, display
server	UserScriptBeforeSessionFailure	session id, username, node host, node port,main session id(*), main session type(*)	-
server,node	UserScriptAfterSessionFailure	session id, username, node host, node port,main session id(*), main session type(*)	session id, username, session type, display, main session id(*), main session type(*)
server	UserScriptBeforeCreateUser	username	-
server	UserScriptAfterCreateUser	username	-
server	UserScriptBeforeDeleteUser	username	-
server	UserScriptAfterDeleteUser	username	-
server	UserScriptBeforeEnableUser	username	-
server	UserScriptAfterEnableUser	username	-
server	UserScriptBeforeDisableUser	username	-
server	UserScriptAfterDisableUser	username	-

(*) 'main session id' and 'main session type' parameters are available only when the user connects to an already running virtual desktop (session shadowing). They indicate the id and type of the session to which the user is connected with his/her own session qualified by 'session id' and 'session type' respectively.

A further key in the node configuration file, allows to run a custom script triggered on change resolution events (resize of the remote screen). The related key is:
UserScriptAfterRemoteResize

Note that the order of parameters is relevant. For example, a custom script to be run on node event 'UserScriptBeforeSessionStart' should use the $2 variable to retrieve username and $4 to retrieve display.

Pre-requisites to run custom scripts
Custom scripts must be executable. Custom scripts set-up in server.cfg are common to all the users who are accessing the server and are executed by the nxserver program. Since nxserver is running as the nx user, you have to grant this user the necessary permissions in order to execute the custom script.

Custom scripts set-up in node.cfg are executed by the nxnode program, which is run as the connected user. Place the script in a directory that is accessible by the node, i.e. accessible by the connected user(s).

By default if the execution of the scripts fails, the nxserver and nxnode will terminate. This means that the user's session will not start. You can override this behavior by forcing exit 0 inside the custom script and let the session start even if the custom script is failed.

If the NoMachine server is a node of a Cloud Server consider that custom scripts have to be placed in server.cfg or node.cfg file on the node, not on the Cloud Server host.

12.6. Accessing Remote Desktops by RDP

RDP sessions are encapsulated inside a virtual desktop session and they use the RDP client. So, prerequisite is that this RDP client (by default rdesktop) is installed on the host machine where the NoMachine RDP virtual desktop will be run, this is likely to be any of the Enterprise Terminal Server Node hosts.

Note that behaviour of RDP sessions is strictly related to features supported by the RDP client. For example, running a Windows application as a single application is possible only if the version of the RDP client supports it.

Support for RDP sessions is not enabled by default in NoMachine Enterprise Terminal Server. To enable it, please follow instructions at: https://www.nomachine.com/AR07J00645

12.7. Accessing Remote Desktops by VNC

VNC sessions are encapsulated inside a virtual desktop session and they use the VNC client. So, prerequisite is that this VNC client (by default vncviewer) is installed on the host machine where the NoMachine VNC virtual desktop will be run, this is likely to be any of the Enterprise Terminal Server Node hosts.

Note that behaviour of VNC sessions is strictly related to features supported by the VNC client.

Support for VNC sessions is not enabled by default in NoMachine Enterprise Terminal Server. To enable it, please follow instructions at: https://www.nomachine.com/AR10K00720

13. Collaborative Virtual Desktops and Connections to the Physical Desktop

---

This section deals with the possibility to share your own remote desktop with other users, included guests, for example for remote assistance or collaboration. Request for desktop owner's authorization is configurable depending on the type of users (guest users always need the explicit approval to connect). Sessions can be in interactive or view-only mode. Allowing connections in interactive mode grants the user full access to the desktop resources and applications. View-only mode is suggested for example when making presentations or teaching a lesson.

13.1. Sharing Virtual and Physical Desktops

By default users can connect to their virtual desktops and to virtual desktops owned by other users as well as to physical desktop of the remote computer. Different users can share the same desktop and access all applications and resources interactively, or assist in view-mode only.

When the desktop owner is different from the connecting user, he/she is always required to authorize the incoming request for connection. Authorization is not requested when the incoming user and the desktop owner are the same. Also system administrators, NoMachine administrators and NoMachine trusted users can connect without explicit authorization.

With the new Guest Desktop Sharing, the desktop owner can authorize a user to connect to the desktop without needing an account for that user. See the relative paragraph in this guide for more details.

Configurations made via the UI apply to connections to physical and virtual desktops. If you want to set a separate configuration for these desktops, you have to edit the server configuration manually.

Rather than allow all users to connect without virtual desktop's owner authorization or click accept for every single user which would like to connect, it is possible to define in advance a number of trusted users who don't need the specific owner's permission. See the relative paragraph.

13.2. Authorization and Interaction Level for Virtual Desktop Sharing

Configuring access authorization

It's possible to configure via UI if system users need or not the desktop owner's approval to connect. Guest users need always the approval.

To configure access for system user, open Settings -> Server -> Security and enable/disable options: 'Don't require acceptance if the user logged in as the owner of the desktop' and 'Don't require acceptance if the user logged in as a system user'.

Settings via UI applies to both virtual and physical desktops.

Otherwise set behaviour only for virtual desktops via configuration in server.cfg. Default corresponds to the following settings:
VirtualDesktopAccess owner,system,trusted,administrator
VirtualDesktopAccessNoAcceptance owner,trusted,administrator

The VirtualDesktopAccess key in server.cfg (which replaces the VirtualDesktopSharing key available in previous versions) accepts a comma-separated list of values to define which kind of user is allowed to connect to the virtual desktops running on the NoMachine server host.

Accepted values are (order of values is not relevant):
VirtualDesktopAccess owner,system,trusted,administrator,guest

administrator: system adminstrators and NoMachine administrators
trusted: NoMachine trusted users for connections to the virtual desktops (nxserver --useredit USERNAME --trusted virtual)
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.
owner: the owner of the remote desktop
guest: Guest Desktop Sharing users (which don't have a system account)

The VirtualDesktopAccess key has to be used in conjunction with the VirtualDesktopAccessNoAcceptance key (previously named VirtualDesktopAuthorization) to define which user can access the remote desktop without the desktop owner's authorization. This key accepts:

VirtualDesktopAccessNoAcceptance owner,system,trusted,administrator

Configuring interactive or view-only mode

It's possible to configure if users will connect in interactive mode or view-only mode via the UI in the Settings -> Server -> Security panel choose 'Only allow connections in view-only mode'

Otherwise you can forbid users to interact with the desktop once connected via configuration by setting in server.cfg:
VirtualDesktopMode 0

To allow full interaction instead, ensure to have:
VirtualDesktopMode 2

A further setting allows instead the connected user to interact with the desktop except for resize operations:
VirtualDesktopMode 1

13.3. Disabling Virtual Desktop Sharing

By default users can connect to virtual desktop sessions owned by a different user. To forbid this capability, set in the server configuration file:
VirtualDesktopAccess none

This setting also disables the listing of other user's virtual sessions in the client User Interface.

13.4. Authorization and Interaction Level for Physical Desktop Sharing

Configuring access authorization

It's possible to configure via UI if system users need or not the desktop owner's approval to connect. Guest users need always the approval.

To configure access for system user, open Settings -> Server -> Security and enable/disable options: 'Don't require acceptance if the user logged in as the owner of the desktop' and 'Don't require acceptance if the user logged in as a system user'.

Settings via UI applies to both virtual and physical desktops.

Otherwise set behaviour only for physical desktop via configuration in server.cfg. Default corresponds to the following settings:
PhysicalDesktopAccess owner,system,trusted,administrator
PhysicalDesktopAccessNoAcceptance owner,trusted,administrator

All users - except guests - can request to connect to the physical desktop owned by another user. The approval of the desktop owner is always requested, except for NoMachine trusted users and administrators and when the connecting user is the desktop owner.

The PhysicalDesktopAccess key in server.cfg (which replaces the PhysicalDesktopSharing key available in previous versions) accepts a comma-separated list of values to define which kind of user is allowed to connect to the physical desktop of the NoMachine server host.

Accepted values are (order of values is not relevant):
PhysicalDesktopAccess administrator,trusted,system,owner,guest

administrator: system adminstrators and NoMachine administrators.
trusted: NoMachine users trusted for connections to the physical desktop (nxserver --useredit USERNAME --trusted physical)
system: all unprivileged users who have a valid account to log-in
owner: the owner of the remote desktop
guest: Guest Desktop Sharing users (which don't have a system account) and System Guest Users (who have instead a system account generated automatically on demand. This type of user is available only on Linux with NoMachine Terminal Server, Enterprise Terminal Server and Enterprise Terminal Server Cluster).

Configuring interactive or view-only mode

It's possible to configure if users will connect in interactive mode or view-only mode via UI
in the Settings -> Server -> Security panel choose 'Only allow connections in view-only mode'

Otherwise you can forbid users to interact with the desktop once connected via configuration by setting in server.cfg:
PhysicalDesktopMode 0

To allow full interaction instead, ensure to have:
PhysicalDesktopMode 2

A further setting allows instead the connected user to interact with the desktop except for resize operations:
PhysicalDesktopMode 1

Others

Always require that a user is actually present in front of the system and accepts the connection
Set in server.cfg:
EnableScreenSharingMode 1
This overrides more permissive settings set in keys LoginScreenAccess, ScreenSharingOwnerAccess and PhysicalDesktopAccessNoAcceptance.

Let the desktop owner access the remote physical desktop also when screen sharing is disabled
Set in server.cfg:
ScreenSharingOwnerAccess 1

Override user's setting to disable 'Desktop shared'
If the user set 'Desktop not shared' from the !M monitor menu of the server, it's still possible to re-enable it via command line.

Execute from a terminal:

$ sudo /etc/NX/nxserver --useredit USERNAME --screen-sharing yes

13.5. Disabling Physical Desktop Sharing

To completely disable connections to the physical desktop, set:
PhysicalDesktopAccess none
In this way, nobody will be able to connect by NoMachine to the physical desktop of this server host.

13.6. Screen Blanking and Automatic Lock of the Physical Screen

NoMachine servers support the screen blanking feature: when active, the local user will see a black screen on the physical monitor while somebody is connected from remote to the physical desktop. Operations made on the physical screen are not shown and the local user cannot interact with the desktop until the remote user logs-out. Control is given back to the local user once the remote user has logged off. Screen blanking is available for physical hosts, it is not supported on virtual machines since it has effect on the physical monitor.

You can activate the screen blanking feature on the server host machine
via the User Interface:
in the Settings -> Server -> Security panel select the 'Blank the physical screen when somebody connects' option.

Otherwise in the node configuration file.
Uncomment and set:
EnableScreenBlanking 1

To disable the screen blanking, set:
EnableScreenBlanking 0

In both cases then restart the server to make this change effective:

$ sudo /etc/NX/nxserver --restart

The screen blanking feature can be used in conjunction with the automatic lock of the remote screen. Even if the user didn't lock the screen before disconnecting from NoMachine, as soon as the screen is unblanked, the system lock screen will be activated automatically to keep the remote desktop protected even when the computer is running unattended.

You can enable the automatic remote screen lock from the User Interface
In Settings -> Server -> Security panel select the 'Lock the physical screen on disconnect' option

or in the server configuration file, server.cfg.
Uncomment and set:
EnableLockScreen 1

To disable the automatic screen lock, set:
EnableLockScreen 0

Then restart the server to make this change effective:

$ sudo /etc/NX/nxserver --restart

14. Device Sharing, Copy&Paste and File Transfer

---

The Enterprise Terminal Server allows users to access and share their devices and resources from local to remote and vice-versa. Disks, printers, USB devices and more can be connected inside the session to easily access them from both client and server side. At present device sharing is not available with web sessions.

Two-way copy and paste is fully supported. In Web sessions the NoMachine virtual clipboard provides for copying text from/to the session running in the browser and the local computer.

Download/upload files from the session to the local computer and vice-versa is also fully supported in client and web sessions, as well as drag and drop of a file from remote to local and from local to remote.

By default device sharing, copy&paste and file transfer are always permitted. You can however completely disable any of these services or disable it only partially, for example to prevent users from sharing their local printer in the NoMachine session but permitting them to use the remote printer.

Edit the configuration file of each host (Enterprise Terminal Server Node) where you want to limit/disable device sharing, copy&paste and file transfer. Then run the following command on the Enterprise Terminal Server Cluster to make changes made on the nodes effective:

$ sudo /etc/NX/nxserver --nodeedit NODE:PORT

As an alternative to edit manually the cfg file on each node, ETSC permits to configure device sharing and other services like copy and paste operations via profile rules. They can be applied to all nodes or to the specified ones.

14.1. Connecting Devices

NoMachine implements a self-contained infrastructure for making available physical and logical devices over the network from local to remote or vice-versa.

The NoMachine infrastructure for device sharing ensures that all services work out of the box without the need for any additional change or configuration. It is possible to connect disks, printers, USB devices, network port and smartcards.

Connecting devices is supported only by NoMachine client (web sessions don't support it). Devices can be connected through the NoMachine menu within the session (ctrl+alt+0 to open it). Connected devices can be disconnected during the life of the session and reconnected later. If option 'Export this deviceName at session startup' is checked in the menu panel, this device is automatically reconnected at the next session start-up.

Disabling device sharing
You can disable selectively the possibility to share a device

from the User Interface
in the Settings -> Server -> Devices panel

or in the node configuration file
by editing the corresponding keys. The manual configuration also allows the service to be limited to one-way, for example forbid to connect a local printer to the remote host. The next paragraphs deal with manual node configurations in detail.

The available devices are:

Devices	Configuration	Technical details
Disks	Local and remote disks can be connected and disconnected during the life of the session and navigated by file browsing. A disk connected as 'Public' is available to all users accessing that desktop. A private disk is available only to the user who connected it. Administrators can configure paths on the server where public and private disks will be mounted as well as specifying which disks on the server can be made available to users.	This service uses FUSE, installed on the Linux system by default. The nxfs and nxfsserver programs are used to mount disks.
Printers	Local and remote printers can be connected at any time (bi-directional printing). A connected printer is listed among the available printers when printing a document or similar. A printer can be connected to be 'Public', i.e. available to all users connected to that desktop, or private, for a specific user. It can be also configured to be the default printer.	This services uses the CUPS infrastructure present on the Linux system. A printer can be exported to the server only if the connected user is in the lpadmin group.
USB devices	USB devices such as disks, pendrives, webcam etc... are forwarded through the network. For example, when a USB device is forwarded from local (where the player is running) to remote, it becomes available on the remote side only.	This service is based only on the NoMachine USB Server (nxusbd) and drivers (the nxusb.ko kernel module for Linux) and doesn't require external tools.
Network ports	Service ports (such as Samba, CUPS, FTP, SSH, telnet and others) can be made available from local to remote and vice-versa via a virtual network interface.	This service relies on a NoMachine tool plus a standard driver.
Smart Cards	A smartcard reader can be forwarded from client to server side and makes smartcard authentication available within the session. The server host must support authentication via smartcard.	Support for authentication with smart card has been set-up by relying on the Public Key Infrastructure (PKI) and requires an OpenSC compatible smart card. It can be integrated with Kerberos ticket authentication and ticket forwarding.

14.2. Disks

NoMachine allows access to local and remote file systems from within the session through the SSHFS file-sharing protocol and by means of FUSE, a technology to implement a fully functional filesystem in a userspace program.

Connected folders and disks can be disconnected during the life of the session or left as they are.

By default, all disks from the server are available to be connected to the end-user's machine. However you can specify a set of disks and folders by editing a proper value for the DiskSharingList key in the node configuration file. The default value is: all. Alternatively, you can specify a list of comma-separated directories. Note that $(HOME) and $(USER) are accepted values.

Disks from the end-user's machine can be connected on the server in 'Public' or 'Private' mode.

Connecting public disks
Disks from the end-user's machine can be connected on the server in 'Public' or 'Private' mode.
By default public disks are exported from player to "$(PUBLIC)" directory on the server, where $(PUBLIC) is: /media on Linux.

You can specify a different path by un-commenting and editing the DiskSharingPublicBasePath key in the node configuration file.
Note that $(USER) is an accepted value that can be also concatenated to specify the path to a directory, for example "/tmp/$(USER)".

The target directory must exist on the system!

Disabling Disks' Connection
To forbid disk and filesystem sharing, uncomment and set a proper value for the EnableDiskSharing key in the node configuration file:
client The filesystem on the client can be connected to server side and accessed from the session.
server The filesystem on the server can be connected to the end-user's machine and accessed through the whole life of the session.
both Client and server filesystem can be connected to remote and local sides respectively.
none Neither client or server filesystem can be connected.

For example, to forbid connecting disks from remote to local side, set in the node configuration:
EnableDiskSharing client

14.3. Printers

The printers sharing infrastructure integrates client-side printers with the server-side printing subsystem and vice-versa. Printers available on the client machine can be shared and used within the session as well as printers on the server side which can be made available on the end-user's machine.

Connected printers can be disconnected during the life of the session or left as they are. In this case, they are automatically shared at the next session start-up.

On Linux this service uses the CUPS infrastructure present on the system. With CUPS 1.4 or later, to ensure that users are able to connect a printer from the local desktop to their NoMachine session on Linux, it's necessary that the user already belongs to the CUPS System Group on the NoMachine server host. This is because in order to add a printer to the CUPS system, the 'lpadmin' command line tool has to be executed by a user who belongs to the CUPS's System Group, which can be for example 'lpadmin' on Ubuntu, 'sys' on Fedora, RHEL and CentOS distributions.

Disabling Printer Sharing
To forbid printer sharing it is necessary to uncomment and set a proper value for the EnablePrinterSharing key in the node configuration file:
client Printers on the client can be connected to server side and made available within the session.
server Printers on the server can be connected to the end-user's machine.
both Client and server printers can be connected to remote and local sides respectively.
none Neither client or server printers can be connected.

For example, to forbid a server-side printer to be connected to the end-user machine, set in the node configuration:
EnablePrinterSharing client

14.4. USB Devices

This service creates a USB tunnel between client and server to forward devices over the network such as hard disk, web cams, barcode readers, and pen drives from local to remote desktops and vice-versa.

Disabling USB Forwarding
To forbid USB device sharing it is necessary to uncomment and set a proper value for the EnableUSBSharing key in the node configuration file:
client USB devices on the client can be forwarded to server side and made available within the session.
server USB devices on the server can be connected to the end-user's machine.
both Client and server USB devices can be connected to remote and local sides respectively.
none Neither client or server USB devices can be connected.

For example, to avoid that users can forward a USB devices from the server to its own machine, set in the node configuration:
EnableUSBSharing client

14.5. Network Ports

NoMachine can create virtual network interfaces and establish a bridge between local and remote sides or vice-versa to provide transparent access to network resources.

This service allows access to any of the default network servers like Samba, CUPS, FTP, SSH and Telnet or any other type, for example a MySQL server.

Connecting a Samba server allows access to resources on that server host via the SMB/CIFS protocol. Connecting a local CUPS server to the remote side allows mounting of printers (local to the user) on that remote CUPS subsystem so that files can be printed on the remote side via the IPP protocol.

Some typical examples of usage:
Print to remote printers from the session
If you have a Linux or Mac machine you can add the local CUPS server via the player toolbar. Choose to add a local server and select CUPS. In this way all printers that are available on your side will be available also on the server and you can print all your documents via the native CUPS (IPP) protocol.

Access a remote host not in your Network Neighborhood
If the remote host has a Samba server, you can add it via the player toolbar. Choose to add a remote server and select Samba as server type. Once that Samba server is added, the remote host shows up in your local Network Neighborhood. You can then connect to remote folders via SMB/CIFS protocol as if that host was in your local network.

Make available a client side HTTP server
You can add your local HTTP server via the player toolbar and make it available on the remote host where your session is running. In this way you can develop and test your web application directly inside the session, without the need for sharing or moving files from remote to local.

Connect to MySQL server behind a firewall
You can choose to add a remote server via the player toolbar. Select 'Custom' and specify MySQL and the port for the MySQL server, by default 3306. Once done, you can connect to that MySQL server via the MySQL client installed on your PC.

Disabling Network Port Forwarding
To forbid network server sharing you must uncomment and set a proper value for the EnableNetworkSharing key in the node configuration file: client Network servers on client side can be connected and made available within the session.
server Network server on the server side can be connected and made available on the end-user's machine.
both Network servers from client and server side can be connected to remote and local sides respectively.
none Neither client or server side network servers can be connected.

For example, to forbid users from connecting their local ports to the server, set in the node configuration:
EnableNetworkSharing server

14.6. Smartcard Readers

When the smartcard reader plugged into the enduser's host is forwarded to the server host, the smartcard authentication is made available inside the session. It can be integrated on with Kerberos Ticket system for example for implementing single sign-on (SSO).

Disabling Smartcard Reader Forwarding
You can enable or disable support for smartcard forwarding by uncommenting and setting the EnableSmartcardSharing key in the node configuration to 1 or 0 respectively.

To disable it set in node configuration file:
EnableSmartcardSharing 0

14.7. Copy and Paste Operations

By default users can copy and paste from local to the session and vice-versa.

You can configure the server to limit such operations by setting proper values in the configuration file as explained below.

Limiting copy & paste operations
You can To forbid copy & paste partially or totally via UI in the Settings -> Server -> Security panel by using the 'Allow the clipboard functionality' option.

Otherwise, you can configure that manually: uncomment and set a proper value for the EnableClipboard key in the server configuration file:
client Content copied on the user's side can be pasted inside the session.
server Content copied inside the session can be pasted on the user's side.
none No copy and paste operations are allowed.
both Two-way copy and paste operations are allowed.

Limiting the Clipboard Buffer
By default, the clipboard buffer is unlimited, but it's possible to limit the amount of data that can be copied from the NoMachine session to the user's device and vice-versa.

To limit the amount of data that can be copied from the session to the user's device, edit the node configuration file on the remote computer and set the appropriate value (in bytes) for this key:
ServerClipboardLimit

For example, to limit the amount of data that can be copied from remote to locale to 4MB, set:
ServerClipboardLimit 4194304

To limit the amount of data that can be copied from the user's device to the NoMachine session, set the ClientClipboardLimit key to the appropriate value.

Setting keys above to 0, means that no limits are applied (default).

14.8. Transferring Files

When a user is connected to the desktop, they have the possibility to transfer files by using the Connection Monitor tool from the system tray within the session. The user can transfer a file from their own PC to the remote host where the session is running and vice-versa. If multiple users are connected, each of them can send a file to a specific user or to all connected users. Drag and drop of a file is also supported

You can manage file transfer
from the User Interface
In the UI -> Settings -> Server -> Security panel

or via node configuration.

Disabling File Transfer
To forbid file transfer you have to uncomment and set a proper value for the EnableFileTransfer key in the node configuration file:
client Files can be transferred from client machine to the server.
server Files can be sent from the server to clients.
both Client and server files can be transferred on remote and local respectively.
none Neither client or server files can be transferred.

For example, to forbid users from transferring a file from the server to their PC:
EnableFileTransfer client

15. Multimedia and Session Recording

---

At the moment audio support in NoMachine sessions relies on PulseAudio or Alsa. For those systems not providing PulseAudio by default, it's advisable to install it manually. Work is in progress to add support also for PipeWire Sound Server. Audio in web sessions requires that WebRTC is enabled. Users can record the NoMachine session or the desktop and save the recordings on their devices. Administrators can activate the automatic recording of a session and store the recordings on the server host (see the related paragraph).

15.1. Supporting Audio and Microphone

On Linux, NoMachine audio framework is integrated with PulseAudio sound server. If PulseAudio is not available on the system, NoMachine is able to use ALSA (Advanced Linux Sound Architecture). This is automatically managed by the NoMachine server so that multimedia support can work out of the box without the need for any configuration. If both PulseAudio and Alsa are available, the administrator might want to configure the node to use one or the other.

Disabling or Setting Audio Support
To disable audio and microphone support, uncomment and set the AudioInterface key to 'disabled' in the node configuration file:
AudioInterface disabled

On Linux it is possible to define whether PulseAudio Server or ALSA has to be used by setting AudioInterface key to 'pulseaudio' or 'alsa' respectively. For example:
AudioInterface pulseaudio

15.2. Recording your Screen

NoMachine can video-record all activity made inside the session or on the local desktop. To start the recording of the session, users should open the NoMachine menu inside the session (ctrl+alt+0) and click on the 'Recording' button icon to access the Recording panel. From this panel it's possible to open the recording bar, change audio and video quality and open the recording directory to access all recorded files. Session recording is not available with sessions on the web.

To record activity made on the desktop, start the recording from the !M icon menu in the system tray of the server host and show the Recording bar from there. Desktop activities can be registered on the physical desktop without the need to be connected by NoMachine.

Recorded files

NoMachine videos are recorded into the new NXR file format which uses the MKV format (Matroska), widely used and supported by the major video players which should be able to play such NXR files without requiring transcoding.

Playback of NoMachine recording files is possible with, for example, Windows Media Player on Windows and with VLC for Windows, Linux and also macOS.

The exception is Apple's Quicktime for macOS. QuickTime doesn't support the MKV format. If using VLC is not an option, it's also possible to install the Perian plugin for Quicktime available at https://www.perian.org/.

Recorded files are saved by default on the user's device in the NoMachine directory under the 'Documents' directory.

Disabling session recording
To prevent users from recording their session activities, edit the node configuration to set:
EnableSessionRecording 0

Disabling desktop recording
To prevent users from recording desktop activities, even when physically logged into the Enterprise Terminal Server host, edit the node configuration to set:
EnableLocalRecording 0

15.3. Automatic Screen Recording

The automatic recording of the session at session startup is disabled by default.

To enable it, execute in a terminal:

$ sudo /etc/NX/nxserver --recording yes

The automatic screen recording applies to both connections to the physical display and virtual desktops.

You can also define the percentage of session to be recorded by specifying the '--percentage PERCENTAGE' parameter or activate the recording for a specific user only or group of users by means respectively of: '--user ' and '--group '.

16. Profiles

---

A profile is defined by a set of rules which restrict the default behavior. For example you can create rules to disable copy&paste, or limit device sharing etc ... Rules can be set:
a) for all users (as an alternative, the same result can be achieved via configuration files)
b) for specific user(s) only
c) for system groups of users
d) for NoMachine groups of users

Support for profiles is enabled by default. It can be disabled by creating the following rules. Disabling profiles doesn't delete the existing rules:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type enable-profiles --value no
To re-enable profiles:
$ sudo /etc/NX/nxserver --ruleadd --class feature --type enable-profiles --value yes

Some definitions

1. Rules are on a per-system basis, if not otherwise specified. It can also be on a per-user or per-group of users basis and per-node basis when applicable.
2. Rules are grouped into classes. The available classes for the Enterprise Terminal Server are: session, service, feature and node. Each class has a number of class types.
3. For each rule it is necessary to define the following items: class, class type, value and eventually option. Option indicates on which basis the rule has to be applied (e.g. per-system, per-user etc...).
4. Rules concerning the server behaviour (enable/disable use of profiles and load-balancing/manual node selection) can be applied only on a per-system basis.

Default profile of NoMachine Server
Until the administrator defines a set of rules, the server relies on its default profile, which allows all the supported functionalities, except for guest users support that must be enabled explicitly in the server configuration.

Resources Availability
The default profile of the server is based on the list of resources available on that host. Setting profile rules is like creating a subset of available resources. When the user logs in to the system, NoMachine Server verifies what is allowed for that user by comparing available resources and the set of profile rules.

To retrieve the list of available resources:

$ sudo /etc/NX/nxserver --resourcelist

Allow and deny class types
A rule to allow or deny a class type (e.g. forbid a session type) or set a behavior (e.g. limit the bandwidth usage) has to be explicitly set, otherwise the server continues to rely on its default behaviour.

If you need, for example, to deny all types of the class features except one, deny all for the whole system and add a rule to allow only this feature.

16.1. Profiles on a Per-system, Users, Groups Basis

Create a profile rule

The general format of the command to create a profile rule is:

$ sudo /etc/NX/nxserver --ruleadd --class CLASS --type TYPE --value yes|no|value OPTION

CLASS, in case of Enterprise Terminal Server, can be any of the following classes:
--session
--service
--feature
--node^(*)
(*)The node class is specific for Enterprise Servers' multi-node environment and allows to limit user's access to a group of nodes.

For each CLASS there is a number of TYPES, which are listed in detail in the following paragraphs.

OPTION can becan be any of the following options, depending on the type of rule:
--system, set the rule on a per-server basis. The rule will be applied to the whole NoMachine system and to every user accessing it. This is the default and can be omitted.
--user USERNAME, set the rule on a per-user basis (USERNAME). The rule will be applied to the specified user only.
--group GROUP, set the rule for the specified GROUP of users. The group can be a system group or a NoMachine group of users previously created.
--guest, the rule will be applied to all guest users and will not affect other users.
--address CLIENT_IP, apply the profile rule according to the IP of the connecting client.
--node NODE:PORT, set the rule for the given node. NODE:PORT is the name of the node, as displayed in the output of the 'nxserver --nodelist' command.
--node-group GROUP, set the rule for the specified GROUP of nodes.

Modify a profile rule

To modify an existing rule, just re-add the same rule by specifying the new value in the --value option.

Delete a profile rule

Do not specify any OPTION if you need to delete all rules. Otherwise you can delete rules on per-user, per-guest or per-group as explained above. The general format of the command is:

$ sudo /etc/NX/nxserver --ruledel OPTION yes|no|value OPTION

16.2. Profile Rules to Forbid Session Types

The available session types are:

Session type	Description
physical-desktop	Connect to the physical desktop of the server host.
unix-xsession-default	Run the default desktop environment as set on the system in a NoMachine virtual desktop
shadow	Connect to a virtual desktop session (desktop sharing/collaboration).
unix-console	Run a virtual Unix console application. It can be embedded into the client session window or be a floating window console depending on the user's choice: run or not the custom session in a virtual desktop
unix-desktop	Run a virtual custom application embedded into the player session window.
unix-application	Run a virtual custom application. It can be embedded into the client session window or be a floating window application depending on the user's choice: run or not the command in a virtual desktop.
unix-gnome	Run a virtual GNOME desktop. The ConnectPolicy key in the server configuration must have 'desktop=1' set.
unix-kde	Run a virtual KDE desktop. The ConnectPolicy key in the server configuration must have 'desktop=1' set.
unix-xdm	Run a virtual desktop through the X Desktop Manager.
unix-default	Run a virtual session by using the default X client script on server.
unix-script	Run a virtual session by using the X client script on server as specified by path.

The general form of the command is:

$ sudo /etc/NX/nxserver --ruleadd --class session --type TYPE --value yes|no OPTION

where TYPE can be any of the available session types, you can retrieve them by:

$ sudo /etc/NX/nxserver --resourcelist --class session --value yes

OPTION can be:
--system, set the rule on a per-server basis. The rule will be applied to the whole NoMachine system and to every user accessing it. This is the default and can be omitted.
--user USERNAME, set the rule on a per-user basis (USERNAME). The rule will be applied to the specified user only.
--group GROUP, set the rule for the specified GROUP of users. The group can be a system group or a NoMachine group of users previously created.
--address CLIENT_IP, apply the profile rule according to the IP of the connecting client. This option can be also used in conjunction with '--user USERNAME' or '--group GROUP' and '--node NODE:PORT' to limit access to an Enterprise Terminal Server Node on aper user/group and IP basis, so that these parameters are evaluated simultaneously.

You can create the rule to forbid any of the supported session types. For example forbid user 'nxtest01' (this has to be an existing user!) to connect to virtual desktops owned by other users (sharing of the virtual desktop):

$ sudo /etc/NX/nxserver --ruleadd --class session --type shadow --value no --user nxtest01

To prevent the 'developers' group (which should already exists and can be either a system group or a NoMachine group) to run RDP sessions:

$ sudo /etc/NX/nxserver --ruleadd --class session --type windows --value no  --group developers

Rules for session types: unix-gnome and unix-kde work only if the server has the ConnectPolicy key enabled with the desktop=1 option set. With this setting, users are entitled to choose between starting a GNOME or a KDE desktop (if both are available on the system).

16.3. Profile Rules to Limit the Number of Sessions

$ sudo /etc/NX/nxserver --ruleadd --class session --type connections-limit --value VALUE OPTIONS 
 nxserver --ruleadd --class session --type virtual-desktops-limit --value VALUE OPTIONS

VALUE is a positive integer. It cannot be higher than the maximum number of connections or virtual desktops specified in the license file (server.lic) in the 'Connections' and 'Virtual Desktops' field respectively. Setting it to 0 means that no limits will be applied, except those coming with the license.

OPTIONS can be:
--system, to set the rule on a per-server basis. The rule will be applied to the whole NoMachine system and to every user accessing it. This is the default and can be omitted.
--user USERNAME, to set the rule on a per-user basis (USERNAME). The rule will be applied to the specified user only.
--group GROUP, to set the rule for the specified system or NoMachine GROUP of users.
--guest, to apply the rule to all guest users. This will not affect other users.
--node NODE:PORT, to apply the rule to the given node. NODE:PORT is the name of the node as it appears in the output of the 'nxserver --nodelist' command.
--node-group GROUP, to apply the rule to all nodes in the given group.

How connections and sessions are counted

The connections-limit counter counts all types of active connections: connections and reconnections to virtual desktops and custom sessions and connections to physical desktop.

When the user connects, the connections-limit counter is always increased. This counter is decreased when the user disconnects.

The virtual-desktops-limit counter counts only new virtual desktops and new custom sessions.

The virtual-desktops-limit counter is increased only when the user creates a new virtual desktop or a new custom session. It's decreased when the user terminates the virtual desktop or the custom session, i.e. it's not decresead when the session is just disconnected.

Some examples
Allow user nxtest01 to have only one active connection. User nxtest01 will be able to create for example one virtual desktop, disconnect and reconnect it but he/she will be not able to have two virtual desktops connected at the same time:

$ sudo /etc/NX/nxserver --ruleadd --class session --type connections-limit --value 1 --user nxtest01

Allow each users of group 'testers' to have maximum 2 virtual desktops at the same time. Each user belonging to group 'testers' will be able to run two virtual desktops or one virtual desktop and one custom session or two custom sessions. No limits are applied when the user connects to another user's virtual desktop or when he/she connects to the physical desktop:

$ sudo /etc/NX/nxserver --ruleadd --class session --type virtual-desktops-limit --value 2 --group testers

Limit to two both the maximum number of concurrent connections and of virtual desktops for all users (option --system can be omitted). Each user will be allowed to have maximum two active connections at the same time and will be able to create maximum two virtual desktops or custom sessions. For example, the user can create one virtual desktop (vd1) and one custom session (cs1). He/she can disconnect and reconnect both vd1 and cs1 but cannot create a new virtual desktop or custom session until vd1 or cs1 is terminated:

$ sudo /etc/NX/nxserver --ruleadd --class session --type connections-limit --value 2
 $ sudo /etc/NX/nxserver --ruleadd --class session --type virtual-desktops-limit --value 2

As an alternative to profile rules, it's possile to use the following keys in the server configuration file: ConnectionsLimit and ConnectionsUserLimit, VirtualDesktopsLimit and VirtualDesktopsUserLimit. These configurations will apply to all users.

The benefit of using profile rules instead of configuration keys is to gain more flexibility thanks to the possibility of setting the rule on per-user/group basis.

It's strongly advisable to not mix the two methods of using profile rules and server configuration.

16.4. Profile Rules for Services (Audio, File Transfer, Printers etc ...)

Two-way services such as printer sharing or USB forwarding can be disabled or enabled on one side only, or on both. To disable or enable the service from client to server, set the rule named as client-servicename (e.g. client-printer-sharing). To completely disable the service, set the rules for both client and server side.

The available services are:

Profiles: TYPE of service	Profiles: possible VALUES	Description	Corresponding key (node.cfg)
audio	yes|no	Support audio streaming from server to user's pc	AudioInterface
microphone	yes|no	Support voice input streaming from user's pc to server side	AudioInterface
client-printer-sharing	yes|no	Connect printers from user's pc to the server side	EnablePrinterSharing
server-printer-sharing	yes|no	Connect printers from server to user's pc	EnablePrinterSharing
client-disk-sharing	yes|no	Connect disks and folders from user's pc to server side	EnableDiskSharing
server-disk-sharing	yes|no	Connect disks and folder from server to user's pc	EnableDiskSharing
client-file-transfer	yes|no	Transfer files from user's pc to the server	EnableFileTransfer
server-file-transfer	yes|no	Send files from server side to a specific user or to all users	EnableFileTransfer
client-network-sharing	yes|no	Connect network ports (SMB, CUPS, ...) from user's pc to server side	EnableNetworkSharing
server-network-sharing	yes|no	Connect network ports (SMB, CUPS, ...) forwarding from server to user's pc	EnableNetworkSharing
session-recording	yes|no	Create and save a video of the session	EnableSessionRecording
local-recording	yes|no	Create and save a video of the desktop of the Enterprise Terminal Server host	EnableLocalRecording
client-usb-sharing	yes|no	Forward a USB device from user's pc to server side	EnableUSBSharing
server-usb-sharing	yes|no	Forward a USB device from server to user's pc	EnableUSBSharing
client-smartcard-sharing	yes|no	Forward a smartcard device from user's pc to server side	EnableSmartcardSharing

The general form of the command to disable a service via profile rules is:

$ sudo /etc/NX/nxserver --ruleadd --class service --type TYPE --value no OPTION

and to enable a service

$ sudo /etc/NX/nxserver --ruleadd --class service --type TYPE --value yes OPTION

TYPE, is any of the type of service listed in the table above.

OPTION can be:
--system, default. It applies to all users.
--user USERNAME, it applies to the given user only.
--group GROUP, applies to all users of the given system or NoMachine group.
--guest, applies to guest users.
--node NODE:PORT, to apply the rule to the given node. NODE:PORT is the name of the node as it appears in the output of the 'nxserver --nodelist' command.
--node-group GROUP, to apply the rule to all nodes in the given group.

If node is not specified, the rule applies to all nodes.

Some examples
Completely disable USB forwarding for all users belonging to the 'developers' group (this group must already exist)

$ sudo /etc/NX/nxserver --ruleadd --class service --type client-usb-sharing --value no --group developers
 $ sudo /etc/NX/nxserver --ruleadd --class service --type server-usb-sharing --value no --group developers

Completely forbid connecting disks for all users. Option --system can be omitted:

$ sudo /etc/NX/nxserver --ruleadd --class service --type server-disk-sharing --value no --system
$ sudo /etc/NX/nxserver --ruleadd --class service --type client-disk-sharing --value no --system

As an alternative to setting profiles, services can be partially or fully disabled also via configuration file by editing the corresponding key in the node.cfg file on each node host where the service has to be disabled. Limiting services via profiles, however, gives a better granularity of control, especially if they don't need to be applied to all users. It's advisable to not mix the two methods, server configuration and profiles.

16.5. Profile Rules for Features (Copy&Paste, Bandwidth usage)

The class 'feature' controls copy and paste operations and can limit the bandwidth usage. It additionally provides the rules to disable/enable profiles.

The available features are:

Profiles: TYPE of service	Profiles: possible VALUES	Description	Corresponding key (node.cfg/server.cfg)
bandwidth	a value in K or M, e.g. '256k', '1m', '100m'	Limit bandwidth usage	in node.cfg ProxyExtraOptions limit=VALUE
client-clipboard	yes|no	Copy and paste from user's device to server side	in server.cfg EnableClipboard
server-clipboard	yes|no	Copy and paste from server side to user's device	in server.cfg EnableClipboard
client-clipboard-limit	a value in bytes e.g. '4194304'=4M	Limit the amount of data that can be copied and pasted from user's device to server side	-
server-clipboard-limit	a value in bytes e.g. '4194304'=4M	Limit the amount of data that can be copied and pasted from server side to user's device	-
enable-profiles	yes|no	Support for profiles	-
node-load-balancing	yes|no	Automatic load-balancing of virtual desktops among the available nodes	-
manual-node-selection	yes|no	Allow users to choose the node where to start their virtual desktops	-

The general form of the command to disable a feature via profile rules is:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type TYPE --value no OPTION

and to enable a feature:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type TYPE --value yes OPTION

TYPE, is any of the type of feature listed in the table above.

OPTION can be:
--system, default. It applies to all users.
--user USERNAME, it applies to the given user only.
--group GROUP, applies to all users of the given system or NoMachine group.
--guest, applies to guest users.
--node NODE:PORT, to apply the rule to the given node. NODE:PORT is the name of the node as it appears in the output of the 'nxserver --nodelist' command.
--node-group GROUP, to apply the rule to all nodes in the given group.

If node is not specified, the rule applies to all nodes.

Some examples
Forbid copy&paste operations for user 'nxtest01' (user must already exists) on all nodes:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type client-clipboard --value no --user nxtest01
$ sudo /etc/NX/nxserver --ruleadd --class feature --type server-clipboard --value no --user nxtest01

Allow to copy and paste from user's device to server side only on node testdrive.nomachine.com:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type client-clipboard --value no 
$ sudo /etc/NX/nxserver --ruleadd --class feature --type server-clipboard --value no
$ sudo /etc/NX/nxserver --ruleadd --class feature --type client-clipboard --value yes --node testdrive.nomachine.com:4000

Limit the amount of data that can be copied and pasted from user's device to remote and vice-versa to 4M on all nodes:

$ sudo /etc/NX/nxserver --ruleadd --class feature --type client-clipboard --value 4194304 
$ sudo /etc/NX/nxserver --ruleadd --class feature --type server-clipboard --value 4194304

16.6. Profile Rules for Limiting Access to Nodes

It's possible to forbid the user or a group of users to connect to a specific node or group of nodes:

nxserver --ruleadd --class node --type NODE:PORT --value no --user USERNAME
nxserver --ruleadd --class node --type NODE:PORT --value no --group USERGROUP
nxserver --ruleadd --class node --type NODE:PORT --value no --address CLIENT_IP
nxserver --ruleadd --class node --type NODE:PORT --value no --user USERNAME --address CLIENT_IP
nxserver --ruleadd --class node --type NODEGROUP --value no --user USERNAME
nxserver --ruleadd --class node --type NODEGROUP --value no --group USERGROUP

In the examples above:
NODE:PORT is the name of a node as it appears in the output of 'nxserver --nodelist'
USERNAME is the name of the user for which the rule is set
USERGROUP is the name of a group of users
--address CLIENT_IP is the IP of the connecting client (it can be also a family of IP adresses, e.g. 11.11.11.*)
NODEGROUP is the name of a group of nodes

17. Automatic Updates

---

The Enterprise Terminal 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.

A separate guide which deals specifically with all the possible options for the automatic software updates is available on the web site in this section:

https://www.nomachine.com/all-documents

 

18. Logging Facilities

---

To retrieve logs by using the NoMachine tools, please refer to guides available in the Configuration section at: https://www.nomachine.com/all-documents.

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.

18.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 /usr/NX/var/log/logrotate directory.

Command to activate log rotation is:

$ sudo /etc/NX/nxserver --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:

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

LOG can be any of these files:
server.log
daemon.log
webrunner.log
htd.log

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

Other commands to manage log rotation

List current settings for log rotation:

$ sudo /etc/NX/nxserver --logrotatelist

Edit parameters set for log rotation:

$ sudo /etc/NX/nxserver --logrotateedit LOG OPTION

Delete all settings for log rotation:

$ sudo /etc/NX/nxserver --logrotatedel

Delete log rotation settings for a specific log file:

$ sudo /etc/NX/nxserver --logrotatedel LOG

It's possible to force log rotation at any moment. This doesn't require enabling it.
This can be helpful for example to debug a problem 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:

$ sudo /etc/NX/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 where to store the rotated files.

 

18.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:

$ sudo /etc/NX/nxserver --restart

18.3. Built-in Audit Tools (Automatic Recording and File Transfer Logging)

Automatic recording

NoMachine has the possibility to enable the automatic recording of the user's session. Users experience inside the session can be captured totally or partially (recording of a given percentage of session) and saved as .nxr files on the server host, to be replayed at any moment by using NoMachine client or whichever other media player supporting H.264 codec.

The automatic recording of the session at session startup is disabled by default.

To enable it on Linux and macOS:

$ sudo /etc/NX/nxserver --recording yes

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe   --recording yes

You can also define the percentage of session to be recorded by specifying the '--percentage PERCENTAGE' parameter or activate the recording for a specific user only or group of users by means respectively of: '--user ' and '--group '.

Recorded files are saved by default in:
%PROGRAMDATA%/NoMachine/var/recording on Windows
/Library/Application Support/NoMachine/var/recording on macOS
/usr/NX/var/recording/ on Linux.

To store them in a different place, provide a path for the NXRecordingDirectory key in the node configuration.

By default the connecting user can accept or refuse to allow NoMachine to automatically record his/her session. It's possible to change this behaviour by setting in the server configuration an appropriate value for the AutomaticRecordingAuthorization key.

Inform the user that his/her session will be recorded, the user cannot refuse that:
AutomaticRecordingAuthorization 0

The user can accept or refuse to allow NoMachine to record his/her session but in this last case the session will be terminated or disconnected in case of a virtual desktop:
AutomaticRecordingAuthorization 2

The connecting user can accept or refuse to allow NoMachine to record his/her session:
AutomaticRecordingAuthorization 1

File transfer logging

It's possible to enable the logging of file transfer operations to the server log file. Such logs contain the word 'Audit' for being easily retrieved.

File transfer operations are not logged by default. To enable the audit, set in the node configuration:

EnableAuditlogs 1

To disable the audit, set:

EnableAuditlogs 0

 

19. Setting-up Centralized Access to Multiple Servers

---

If you own multiple installations of Enterprise Terminal Server, you may need to provide your users with a single point of access to all of these servers. This can be done by installing any of the NoMachine Cloud Server products on a dedicated host and add each Enterprise Terminal Server to it.

The available products are conceived to fit different business sizes, even from a pricing perspective and are: Small Business Cloud Server, Cloud Server, Enterprise Cloud Server and Enterprise Cloud Server Cluster. For simplicity, we refer below to 'Cloud Server', which can be any of those products.

19.1. Setting-up Central Access to the Server

When added to the Cloud Server, the Enterprise Terminal Servers become 'nodes' of that Cloud Server.

In this way, users will connect to the hostname/IP of the Cloud Server and will be redirected to the appropriate Enterprise Terminal Server or, depending on the Cloud Server configuration, will be able to choose it manually.

When the Enterprise Terminal Server is part of a Cloud Server multi-node setup, by default it will still accept connections to its IP/hostname, unless you configure it differently.

To grant high available access to this centralized system, it's possible to add a second Cloud Server to the first one and set-up a failover cluster. This is supported only by the product Enterprise Cloud Server Cluster.

For detailed instructions to set-up the multi-node environment, please refer to the Cloud Server guide appropriate for your product, https://www.nomachine.com/all-documents.

A Cloud Server can be the front-end of different NoMachine servers, even in a multi-level setup. Only the free NoMachine product cannot be part of a Cloud Server setup.