Knowledge Base

Searching in : Document

ID: DT07S00246

Version: NoMachine 8

Added on: 2022-09-13

Last Update: 2024-07-16

Print this article

PDF version

NoMachine Enterprise Desktop - Installation and Configuration Guide

Table of Contents

Introduction

Welcome to the NoMachine Enterprise Desktop - Installation and Configuration Guide v. 8.

1. NoMachine Enterprise Desktop Installation and Configuration Guide

What is NoMachine Enterprise Desktop for?
NoMachine Enterprise Desktop is a standalone server that provides unlimited concurrent access to the same physical desktop of its host. Designed for work sharing sessions and real-time collaboration, remote teaching or assistance, it can be configured for full interaction with the desktop or view-only mode.

Available for Linux, Raspberry, Windows & Mac, the Enterprise Desktop accepts connections via a browser (thanks to its built-in web server) or via NoMachine client.

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

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

The 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. Otherwise you can use the server's remote administration UI: open the client UI on your computer, select the remote server that you want to administer in the 'Machines' panel and mouse click to open the menu. Choose 'Server admin' and login as administrator to that 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 Desktop comes also with a client UI for running sessions and connecting to other remote NoMachine servers. The same UI can be also used by administrators to 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 is conceived to provide a fully operative NoMachine server with a default configuration suitable for the greatest part of environments. All the necessary services are automatically started.

An autonomous server or a node of a cloud server
NoMachine Enterprise Desktop, available for Linux, Raspberry, Windows & Mac, supports multiple concurrent connections to the physical desktop (sharing of the same desktop) of its host machine. The number of users is not limited. NoMachine Enterprise Desktop is a single server (standalone server), to all effects.

If the Enterprise Desktop is used as node of a cloud server,it still accepts accept direct connections to its IP/hostname, unless configured differently.

1.1. About This Guide

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

BaseDirectory
is the base directory where the NoMachine binaries and libraries are installed.

By default, BaseDirectory is:
/usr on Linux
C:\Program files for 64bit packages on 64bit systems, C:\Program files (x86) for 32bit packages on 64bit systems
/Applications on Mac.

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

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 on Linux and Mac using the sudo utility or as root. On Windows they can be run from a command prompt (cmd.exe) executed as administrator.

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

$ /etc/NX/nxserver  --help

on Windows open a CMD console as administrator, then execute the command:

E.g.:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --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 included the NoMachine Forums, tutorials and FAQs: https://www.nomachine.com/support

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

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

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

2. Install, Update or Remove the Enterprise Desktop

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). In some corporate network configurations this can lead to opening ports on unintended interfaces, which can have an impact on the security level established by company strict policies. In this case administrators should install the NoMachine server package with the appropriate option to not start services automatically, see the related paragraph 2.8. in this guide. Then they need to change the configuration of nxhtd as explained here: https://www.nomachine.com/AR07S01137.

2.1. Install the Enterprise Desktop

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

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

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

Raspberry Pi 2/3/4 ARMv6/ARMv7/ARMv8

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

Software requirements
In order to connect by NoMachine to the desktop of a Linux host, a desktop environment must already be installed. This applies also to headless Linux machines. Connections by web and by NoMachine clients are supported.

Compatibility with older versions
Even if it's advisable to upgrade client installations to the same version 8 of the Enterprise Desktop, compatibility with clients v. 7 and 6 is preserved.
Enterprise Desktop v. 8 can work as a node of Cloud Server v. 7 but it's strongly suggested to upgrade the whole multinode environment, included the clients on the users' devices, to the same v. 8 as soon as possible to benefit from all new features sported by that version.

2.2. Windows Installations

INSTALL
Download the package for Windows from the NoMachine web site and install it by double-clicking on the icon of the executable: a setup wizard will take you through the installation.

Reboot the machine; this is mandatory for completing the installation.

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

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

run respectively:

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

It's also possible to specify a non-default location:

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

To skip the installation of USB modules, specify the usbinstall=0 option:

> nomachine-packageName_packageVersion.exe /usbinstall="0" /silent "
or:
> nomachine-packageName_packageVersion.exe /usbinstall="0" /verysilent"

Note that next updates via command line will still require to specify the usbinstall=0 option to skip the installation of USB modules. If you don't specify it, the USB module will be installed.

UPDATE
The update procedure for server and node installations requires you to stop all NoMachine services in order to correctly replace libraries and binaries. This implies that the Enterprise Desktop 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:

Automatic updates
You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and open the Settings-> Server -> 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 by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.
Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.
You can find detailed instructions for configuring the Automatic Updates in a separate document available at: https://www.nomachine.com/all-documents .
Update with NoMachine packages
Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.
If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

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

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

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

On Windows 7 and Vista, click on the Start button and click to open the Control panel from the Start menu. Then access panel 'Programs and Features' or 'Add or Remove Programs', depending on your Windows version.

Reboot is requested to complete the uninstall process.

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

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

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

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

2.3. Mac Installations

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

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

To install from the command line, run:

$ NXMOUNTDIR=$(echo `hdiutil mount nomachine-enterprise-desktop_version.dmg | tail -1 | awk '{$1=$2=""; print $0}'` | xargs -0 echo)

$ sudo installer -pkg "${NXMOUNTDIR}/NoMachine.pkg" -target /

There are two ways to update your current installation:

Automatic updates
You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and open the Settings -> Server -> 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 by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.
Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.
You can find detailed instructions for configuring the Automatic Updates in a separate document available at: https://www.nomachine.com/all-documents .
Update with NoMachine packages
Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.
If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

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

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

$ sudo rm -rf /Applications/NoMachine.app

2.4. Linux Installations

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

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

Successive updates
The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. This implies that the Enterprise Desktop 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:

Automatic updates
You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and open the Settings -> Server -> 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 by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation.
Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option.
You can find detailed instructions for configuring the Automatic Updates in a separate document available at: https://www.nomachine.com/all-documents .
Update with NoMachine packages
Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation.
If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

2.5. RPM Packages

If you want to install to the 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-desktop

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-desktop

2.6. 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-desktop

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-desktop

2.7. TAR.GZ Packages

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

INSTALL

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

UPDATE

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

UNINSTALL

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

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

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

2.8. Installing Without Starting NoMachine Services Automatically

The install procedure automatically starts all the required services without the need for further manual operations. Only in the case of Windows is it mandatory to reboot the machine to complete the installation and ensure that all the required services are up and running.

It may be necessary in some cases, for example because of Company policies, that NoMachine services are not started automatically during the installation.

If the configuration of your network requires to restrict or specify on which ports the NoMachine built-in Apache web server should listen, configure nxhtd as explained here: https://www.nomachine.com/AR07S01137 before starting NoMachine services manually!

Disabling the automatic start of services can be done manually by means of the following commands.

Linux
Export the NX_NOSTART=1 variable while installing the package from a terminal with the usual commands:

$ sudo NX_NOSTART=1 dpkg -i <nomachine DEB package>
$ sudo NX_NOSTART=1 rpm -ivh  <nomachine RPM package>
$ sudo NX_NOSTART=1 tar xvzf  <nomachine TAR GZ  package>
$ sudo NX_NOSTART=1 /usr/NX/nxserver --install

To start NoMachine services after the installation:

$ sudo /etc/NX/nxserver --startup

Windows
Install the package in silent or very silent mode from a CMD console launched as administrator and specify the /nostart=1 switch:

> nomachine-packageName_packageVersion.exe /verysilent /nostart=1
> nomachine-packageName_packageVersion.exe /silent /nostart=1

Rebooting Windows is necessary to complete the installation. Rebooting will start the NoMachine services.

macOS
Create the /tmp/NX_NOSTART file before installing the NoMachine DMG package (double click on it). To install from command line:

$ touch /tmp/NX_NOSTART 
$ hdiutil mount nomachine-packageName_packageVersion.dmg
$ cd /Volumes/nomachine-packageName/
$ sudo installer -pkg NoMachine.pkg -target /

To start NoMachine services after the installation:

$ sudo /etc/NX/nxserver --startup

2.9. Installing the License (for Customers)

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

IMPORTANT:
The server will cease to work once the license is expired.
If this server is a node of a cloud server and has an expired license, it will be still shown in the UI but its status will be marked as 'failed' since it is no longer able to accept connections.
Please contact your NoMachine provider or the Support Team for license renewal options.

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

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

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

On Linux and macOS:

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

On Windows:

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

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

On Linux and macOS:

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

on Windows, open a CMD console as administrator and:

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

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

Pre-requisite: you need to have a valid account on the the Enterprise Desktop host, 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.

3.1. Connecting by Browser Via Enterprise Desktop Web Tools

Once installation is complete, Enterprise Desktop is ready to go.

Point the browser on your device to:

https://SERVER:4443

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

E.g., if Enterprise Desktop 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 Enterprise Desktop host and connect.

Auto-reconnection is supported: when the connection is lost for whatever reason (including when the 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

3.2. Connecting by NoMachine Client

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

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

You can find a step-by-step tutorial for connections to NoMachine in the 'Tutorials' section at: https://www.nomachine.com/all-documents. The tutorial deals with connections using the free NoMachine package, but it is suitable also for being used as a client for connections to the Enterprise Desktop host. If you're using the Enterprise Client, please see also 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 UI 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.

3.3. Preventing Users from Storing their Credentials

To prevent NoMachine users from storing their credentials when connecting to this Enterprise Desktop, use the EnableClientCredentialsStoring key in the server configuration file:
BaseDirectory/NX/etc/server.cfg on Linux
BaseDirectory/NoMachine/etc/server.cfg on Windows
/Applications/NoMachine.app/Contents/Frameworks/etc/server.cfg on Mac

The EnableClientCredentialsStoring accepts any these values:
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

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 desktop 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 users are anonymous.

Guest Desktop Sharing is not enabled by default.

To enable Guest Desktop Sharing via UI:
(i) open the server UI on the Enterprise Desktop 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.

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

Edit the server.cfg file on the Enterprise Desktop host 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, the PhysicalDesktopAccess key allows 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
owner: the owner of the remote desktop
guest: Guest Desktop Sharing users (which don't have a system account)

4. Configuring NoMachine Enterprise Desktop

Most of the configurations can be done via User Interface in the server settings either via the local UI or the remote server administrator's UI. You don't need to edit manually the configuration files unless you need very specific settings.

4.1. Configuring Web Sessions

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:
BaseDirectory/NX/etc on Linux
BaseDirectory/NoMachine/etc on Windows
/Applications/NoMachine.app/Contents/Frameworks/etc on Mac.

For example on Linux it is: /usr/NX/etc/server.cfg.

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 to the localhost, it's necessary to manually update the list of known hosts as explained here: https://www.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 for Linux and macOS:
Protocol system
Port 22

and for Windows:
Protocol system
Port 4022

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

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://www.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 only for NX protocol, instructions to set it up are available here: https://www.nomachine.com/AR03Q01020

Server configuration:
by default the nxd service in charge of accepting connections by NX protocol listens on port 4000.
On Linux and macOS, connections by SSH relies on the system SSHD and default port 22.
On Windows, NoMachine ships its own nxsshd service, listening on port 4022.
In order to change the port for NX protocol, change the port for the nxd service via UI in the Settings -> Server -> Ports panel.
To change the port for connections by SSH to Linux and macOS hosts, modify the listen port for the SSH server on the system and restart it.
On Windows instead, change the port for the nxsshd service via NoMachine UI.

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 Enterprise Desktop host when connecting by the web, set the following key. This is the default:

EnableWebConnectionName 0

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

EnableWebConnectionName 1

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

and to show it (this is the default):
EnableWebMenuTutorial 1

Allowing nxhtd (the NoMachine built-in web server) to serve content of Web Player
EnableWebPlayer 1

4.2. Managing Enterprise Desktop Web Services

The NoMachine web server, nxhtd, is based on Apache web server.

You can start and stop it from the UI in Settings -> Server -> Ports. From there you can also specify whether the service has to be automatically restarted at the next reboot or not.

To stop, start or restart nxhtd from command line on Linux or macOS, open a terminal and execute respectively:

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

On Windows, launch a CMD console as administrator execute:

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

Automatic restart of the nxhtd service
The nxhtd service is automatically restarted at the next boot. You can change the default behavior for the nxhtd service from the UI or by using the following command:

nxserver --startmode nxhtd manual
or to enable the automatic restart of the service:
nxserver --startmode nxhtd automatic

The nxserver --startmode command (as well as the UI setting) operates on the StartHTTPDaemon key in the server.cfg file:

StartHTTPDaemon Automatic

and:

StartHTTPDaemon Manual

Disabling connections by the web
Edit the server configuration file and remove HTTP from the ClientConnectionMethods key. It should then look like:
ClientConnectionMethods NX,SSH

Then restart NoMachine server to make this change effective:

nxserver --restart

4.3. Using an Alternative Apache Web Server

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

However, it is possible to run the web player application with an alternative Apache web server. Look for detailed instructions in our Knowledge Base, section Articles, by searching for the 'Apache' keyword: https://kb.nomachine.com

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

The implementation of WebRTC support in browser-based remote desktop sessions must be enabled explicitly by the administrator by editing the server.cfg file.

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

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

AcceptedWebMethods webrtc

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

Section "STUN"

Host hostname
Port portnumber
User username
Password password

EndSection

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

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

5. 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.

5.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 WebRTC to be enabled and a browser which supports WebRTC and HTML5.

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

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

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 Desktop host machine has a hardware accelerated video cards (GPU) with Nvidia Kepler microarchitecture (or later), or Intel Quick Sync processors or AMD cards.
Enabling HW acceleration using Quick Sync requires 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.

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
This will disable the progressive refinement of the image from the lower quality version of the image during moments of inactivity of the desktop till the target quality set in the Display quality slider. Disabling this refinement will send the image directly with target quality. This is not recommended when there is a very limited bandwidth.
Enabling WebRTC
NoMachine web sessions use by default the classic web media exchange protocol for the 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 for H.264 video streaming (when possible) or VP8, both which optimize the user's 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.

5.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 H.264 (default) and VP8 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 UI
In the UI in the Settings -> Server -> Performance panel.

or in the node configuration file, node.cfg:

EnableDisplayServerVideoCodec 1
DisplayServerVideoCodec CODEC

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

6. Enterprise Desktop Configuration

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

6.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 the:
BaseDirectory/NX/etc directory on Linux

BaseDirectory/NoMachine/etc directory on Windows

/Applications/NoMachine.app/Contents/Frameworks/etc/ directory on Mac.

The Default Configuration
NoMachine Enterprise Desktop comes with a default configuration that is sufficient to grant a working setup in the majority of environments. You can tune your server installation at any moment and according to your specific needs by setting the related configuration keys. In some cases this will require the 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. For example 'vi' can be used on Linux and Mac, and 'notepad' on Windows. On Windows it might be necessary to copy the cfg file to a different place, edit it and then move it to the etc directory.

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

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 connection without the need to restart the server if not otherwise specified.

7. Services Management

Installation and upgrade procedures take care of configuring and starting all the necessary services to make NoMachine Enterprise Desktop ready to accept connections to its physical desktop. The necessary services are configured to be restarted at each reboot of the host machine.

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

When you are sitting in front of the computer where Enterprise Desktop is installed or you're connected there by NoMachine, you can switch off/on the ability to accept connections to the 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:
EnableAcceptingConnection 0
Be sure to remove the pre-pending # from the key name.

7.2. Stopping and Starting Server (nxserver) and Services

All NoMachine services can be stopped/started via:

the UI
all NoMachine services can be stopped by the UI in the Settings -> Server -> Status panel.
Clicking on 'Shut down the server' will terminate all users' connections and current sessions. When doing so, you will be asked if services must be started at the next reboot or not.

To stop only incoming new connections and preserve current connections and sessions, you can choose 'Stop the server'.

In the same panel, you can then restart server and services by clicking on 'Restart the server'. This will temrinate all running sessions.

or from command line.

Shutdown all services and terminate all connections and running sessions
On Linux and macOS:

$ sudo /etc/NX/nxserver --shutdown

By default, all services will be restarted when the machine is booted. To override this behavior, specify the start mode when stopping the services:

$ sudo /etc/NX/nxserver --shutdown --start-mode manual

On Windows:

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

or, to not restart automatically the service at next reboot:

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

Restart all services after a shut down

On Linux and macOS:

$ 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

To restore the automatic starting of services when rebooting:

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

On Windows:

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

To not start services when the machine is rebooted:

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

To restore the automatic starting of services when rebooting:

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

Do not accept new connection but preserve current connections and running sessions

On Linux and macOS:

$ sudo /etc/NX/nxserver --stop

On Windows:

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

Enable accepting new connections again

On Linux and macOS:

$ sudo /etc/NX/nxserver --start

On Windows:

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

Shutdown all services (this will terminate all running sessions) and then start all the services

On Linux and macOS:

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

or:

$ sudo /etc/NX/nxserver --restart

On Windows:

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

or:

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

7.3. Stopping and Starting nxd, nxhtd and nxsshd

The NoMachine network services available for NoMachine Enterprise Desktop are nxd, nxhtd (both installed on all platforms) and nxsshd (installed on Windows only):

Program	Default port	Scope	Available on
nxd	4000	Accept connections by NX protocol	Linux, Windows and Mac
nxhtd	4443	Accept connections by HTTPS protocol (connections by the web)	Linux, Windows and Mac
nxsshd	4022	Accept connections by SSH protocol	Windows

You can stop a single service:

via the UI
in the Settings -> Server -> Ports -> panel. You can also choose the start mode there: whether the service must be started automatically at the next boot or not. From the same panel, you can then start the service.

or from command line.

On Linux and macOS:

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

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

On Windows:

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

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

Specify if the service has to be started in 'automatic' or 'manual mode by adding it to the command:
nxserver --startmode SERVICE manual
nxserver --startmode SERVICE automatic

Commands to stop/start services operate on the configuration keys listed below. You can also change them manually in the server configuration.

Configuration	Key setting
Enable automatic starting of nxd	StartNXDaemon Automatic
Disable automatic starting of nxd	StartNXDaemon Manual
Enable automatic starting of nxhtd	StartHTTPDaemon Automatic
Disable automatic starting of nxhtd	StartHTTPDaemon Manual
Enable automatic starting of nxsshd on Windows	StartSSHDaemon Automatic
Disable automatic starting of nxsshd on Windows	StartSSHDaemon Manual

7.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 free, 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 EnableNetworkBroadcast 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.
22 (Linux and Mac)	TCP port for connections via SSH protocol on Linux and Mac. 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.
4022 (Windows)	TCP port for the NoMachine SSH server on Windows (nxsshd) and connections by SSH protocol. This port must be open in the firewall and mapped to the external IP of the server host.	Set SSHPort in server.cfg and restart the nxsshd service.
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
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.
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

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

When the !M (the Monitor) icon is visible in the system tray, it is possible to hide or show the 'Show server status' item displayed in the menu.

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

Then restart NoMachine server, via UI or from command line.
On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --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.

7.6. Hiding the Whiteboard and Chat Tools

If you want to disable the possibility of launching the Whiteboard from the Monitor menu, edit the node configuration file to have:

EnableWhiteboard 0

Then restart the server, via UI or from command line.

7.7. Discovering this Server on LAN

By default NoMachine Enterprise Desktop broadcasts information to let other NoMachine computers discover it on the local network. You can disable this feature via:
the UI
in the Settings -> Server -> Ports panel: uncheck option 'Advertise this computer on the local network'.

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

EnableNetworkBroadcast 0

Then restart the server via UI or from command line.

8. 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.

8.1. Whiteboard and Custom Notifications

NoMachine provides an instant messaging tool, named whiteboard which allows also drawing and sharing files with connected users and fast-track access to file transfer. Mouse click on the !M icon in the system tray of the Enterprise Desktop host and click on 'Show whiteboard'. Note that if multiple users are connected at the same time, they will all see the message.

Sending a message to all sesions or to a specific session

On Linux and Mac execute in a terminal any of the following commands:

$ sudo /etc/NX/nxserver --broadcast "Your message goes here"
$ sudo /etc/NX/nxserver --message  	<sessionid> "Your message goes here"

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

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --broadcast "Your message goes here"
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --message <sessionid> "Your message goes here"

9. Supported Connection Protocols and Authentication Methods

NX Protocol
NoMachine 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 a 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 the 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 Desktop also provides tunneling of connections using SSH and full integration with any authentication backend supported by the host SSH server. On Windows systems, NoMachine provides a built-in SSH server, nxsshd.

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 a SSH agent	-	yes
Login with SSH private key stored on a PKCS11 smart card	yes	yes
Login with Kerberos ticket on client side	yes	yes
Support for SSH agent forwarding	-	yes
Support for Kerberos tickets authentication forwarding	yes	yes
Support for two-factor authentication	yes	yes

For more details about integrating NoMachine with various authentication methods, please refer to the correspondent guide in the 'Configuration' section at: https://www.nomachine.com/all-documents

9.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,HTTP

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.

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

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

9.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 you can change it later: mouse click on the connection icon -> Edit connection -> Address. Select the Protocol and switch to the 'Configuration' tab from the menu on the left.

9.3. Changing Port for the NX Protocol

By default nxd is listening on port 4000 to accept connections by NX protocol.

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

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

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

Restart nxd via UI or from command line.

When NX protocol is used, UDP communication for multimedia is enabled by default.

9.4. Changing Port for the SSH Protocol

The default port used for the SSH protocol is 22 on Linux and Mac. On such platforms 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 client UI.

To align the server configuration, change the SSH port via UI in the Settings -> Server -> Ports panel

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

On Windows, NoMachine provides the SSH server, nxsshd, listening on port 4022. As explained above, this port can be changed from the UI or in the server configuration file (SSHPort 4022).

Restart nxsshd via UI or from command line.

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

9.5. Connecting to a Server Behind a NAT Router (UPnP Port Mapping)

Automatic discover of the NoMachine Enterprise Desktop 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 Enterprise Desktop.

When the server is behind a NAT router, you have to configure the router to map an external port to the internal port 4000 for connections by NX protocol, or 22 or 4022 (Windows) for connections by SSH. This is called 'port forwarding' or 'port mapping'.

If the router supports UPnP/NAT-PMP, you can let NoMachine Enterprise Desktop try to enable port forwarding in the router automatically. External ports will be selected randomly from the 20000 - 30000 range.

Users connecting to the Enteprise Desktop will have to specify the external port in their connection settings in the client UI.

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 permit 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 UI
via the Settings -> Server -> Ports panel. Selecting the service and 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 via command line. You can also start and stop the port mapping via command line.

On Linux and macOS 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 SECONDS

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --upnpunmap
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --upnpmap
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --upnpmap --time SECONDS

9.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.

9.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

10. 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.

10.1. Managing Local System Accounts on the Enterprise Desktop Host

To be able to login to the Enterprise Desktop host, you need to have a valid account on that host, 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.

On Linux and macOS:

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

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --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.

On Linux and macOS:

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

On Windows:

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

Enabling and Disabling NoMachine access for a given user

Prerequisites are:

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

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

Then, on Linux and macOS:

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

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userenable USERNAME
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userdisable 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. To retrieve the complete list on Linux and macOS:

$ sudo /etc/NX/nxserver --userlist

On Windows:

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

Override user's setting to disable 'Desktop shared/Desktop not shared' in !M menu

If the user disabled 'Desktop shared' from the !M monitor menu of the Enterprise Desktop, it's still possible to re-enable it via command line.

On Linux and macOS:

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

On Windows:

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

10.2. Connecting with a Privileged System Account

By default, NoMachine allows the running of sessions as privileged system user ('root' on Linux and Mac and an administrator on Windows). 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

10.3. Managing the Desktop Owner's Authorization (Trusted Users & NoMachine administrators)

By default when the connecting user is different from the owner of the physical desktop, the desktop owner has to authorize that user for the connection. This applies when the owner of the desktop is physically logged-in to that host and when the owner logged-in by NoMachine.

The authorized user - who is not the owner- cannot instead accept or refuse the connection request of another user. We have in plan to give the possibility to define a list of connected users who can authorize other users to connect to the desktop even if they don't own the desktop.

Only system administrators, NoMachine administrators and NoMachine trusted users can connect without explicit authorization.

It's possible to configure via UI if system users need or not the desktop owner's approval to connect. Guest Desktop Sharing 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'.

Behaviour can be configured also via configuration in server.cfg. Default corresponds to the following settings:
PhysicalDesktopAccess = owner, system, trusted, administrator
PhysicalDesktopAccessNoAcceptance = owner, trusted, administrator

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 = owner, system, trusted, administrator, guest

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)

The PhysicalDesktopAccess key has to be used in conjunction with the PhysicalDesktopAccessNoAcceptance key (previously named PhysicalDesktopAuthorization) to define which user can access the remote desktop without the desktop owner's authorization. This key accept the same values as the PhysicalDesktopAccess key:

PhysicalDesktopAccessNoAcceptance administrator,trusted,system,owner,guest

For example:
disable the request for desktop owner's authorization for all users
Set in the server.cfg file:
PhysicalDesktopAccessNoAcceptance administrator,trusted,system,owner,guest

Allow only NoMachine trusted users to connect without authorization
Set in the server.cfg file:
PhysicalDesktopAccessNoAcceptance trusted

NoMachine administrators and trusted users

Being a NoMachine administrator doesn't alter current system privileges for that user. To make a user becoming a NoMachine administrator, do the following.

On Linux and macOS:

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

On Windows:

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

NoMachine trusted users have the ability to connect to the remote desktop without the need to be authorized. It's also possible to define NoMachine groups of users and make them trusted, or make trusted already existent system groups (on Linux and Mac only). It's also possible to limit the trusted attribute to those desktops owned by specific users.

Make a user trusted
On Linux and macOS:

$ sudo /etc/NX/nxserver--useredit USERNAME --trusted physical
To make the user trusted only for the desktop of a specific user (USERNAME2 can be also a list of comma-separated users):
$ sudo /etc/NX/nxserver --useredit USERNAME --trusted physical --per-user USERNAME2

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --trusted physical
To make the user trusted only for the desktop of a specific user (USERNAME2 can be also a list of comma-separated users):
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --useredit USERNAME --trusted physical --per-user USERNAME2

Remove the 'trusted' attribute
On Linux and macOS:

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

On Windows:

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

List only trusted users
On Linux and macOS:

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

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --userlist --trusted

11. 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 Desktop can be in any of the following statuses:
Connected - when it's connected to the remote display.
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 and Terminating.

NoMachine Enterprise Desktop is able to manage only connections to the remote physical desktop.

11.1. Monitoring Sessions

You can monitor sessions from command line tools.

Listing Running Session

On Linux and macOS:

$ sudo /etc/NX/nxserver --list

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

On Windows:

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

You can also filter results on a per-user basis:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --list USERNAME
and/or gather further information about connected clients:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --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 istory configuration (SessionHistory key in server.cfg). The session history allows to see the complete list of sessions, including those that have been cleanly terminated or failed, debug a failed session and generate statistics of sessions.

On Linux and macOS:

$ sudo /etc/NX/nxserver --history

To redirect the output of the session history to a file:
$ sudo /etc/NX/nxserver --history --file FILE

If you want to filter results on a per-user basis:
$ sudo /etc/NX/nxserver --history USERNAME

or to get details about a session:
$ sudo /etc/NX/nxserver --history SESSIONID

On Windows:

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

To redirect the output of the session history to a file:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history --file FILE

If you want to filter results on a per-user basis:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history USERNAME

or to get details about a session:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history SESSIONID

Run the --history command with the --verbose option 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 provides a short report helpful for a preliminary debug of the problem.

On Linux and macOS:

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

You can also redirect the error report to a file:
$ sudo /etc/NX/nxserver --history ID_of_FAILED_SESSION --file FILE

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history ID_of_FAILED_SESSION

You can also redirect the error report to a file:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history ID_of_FAILED_SESSION --file FILE

Retrieving Statistics about Sessions with Session History

It 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.

On Linux and macOS:

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

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

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history --stats

To redirect statistics to a file:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history --stats --file FILE

Clearing Sessions History

You can reset the history.

On Linux and macOS:

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

On Windows

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --history clear

Configuring the Session History Backlog

Data is preserved for 30 days. You can modify that 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.

11.2. Managing Sessions

Terminating Sessions Automatically

If you need to terminate a remote desktop session after a certain time of inactivity, you can specify it by uncommenting and adding the '-timeout s' (s stays for seconds) option to the DisplayAgentExtraOptions key in the node configuration file.

For example, if you want to terminate sessions after 10 minutes of inactivity you need to set:
DisplayAgentExtraOptions "-timeout 600"

If the NoMachine display agent doesn't receive any input from the user in the given timeout, it will terminate the session.

Terminating the Session from Command Line

On Linux and macOS;

$ sudo /etc/NX/nxserver --terminate SESSIONID
or:
$ sudo /etc/NX/nxserver --terminate DISPLAYID

To terminate all sessions of a certain user, run instead:
$ sudo /etc/NX/nxserver --terminate USERNAME

If you want to terminate all sessions, just restart the server:
$ sudo /etc/NX/nxserver --restart

If you want to terminate all sessions and forbid new connections until the server is started again:
$ sudo /etc/NX/nxserver --shutdown

On Windows:

> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --terminate SESSIONID
or:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --terminate DISPLAYID

To terminate all sessions of a certain user, run instead:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --terminate USERNAME

If you want to terminate all sessions, just restart the server:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --restart

If you want to terminate all sessions and forbid new connections until the server is started again:
> %ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe  --shutdown

Limit the number of concurrent connections

The maximum number of concurrent connections to the physical desktop is defined in the server configuration (twenty by default). Set a different value in this key to increase or decrease the limit:
ConnectionsLimit 20

It's also possible to limit the maximum number of connections that per user by editing in server.cfg:
ConnectionsUserLimit 20

Limits above can be used in conjunction with the AutomaticDisconnection key which controls the server behaviour when the maximum number of allowed connections is reached:
AutomaticDisconnection 0 The server prompts the connected user to accept or refuse to disconnect for making room for the incoming user. If no choice is made, the user is automatically disconnected. This is the default.
AutomaticDisconnection 1 The server automatically disconnects the connected user to make room for the connecting user. No message is issued to the already connected user.
AutomaticDisconnection 2 The server prompts 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 advises the incoming user that the maximum number of allowed connections is reached.
AutomaticDisconnection 3 The server never notifies desktop owners about incoming users, incoming users are informed that the maximum number of allowed connections has been reached.

11.3. 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

Keys and parameters not supported by the Enterprise Desktop are omitted in the table below.

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	session id, username, session type, display
server,node	UserScriptAfterSessionStart	session id, username, node host, node port	session id, username, session type, display
server,node	UserScriptBeforeSessionClose	session id, username, node host, node port	session id, username, session type, display
server,node	UserScriptAfterSessionClose	session id, username, node host, node port	session id, username, session type, display
server	UserScriptBeforeSessionFailure	session id, username, node host, node port	-
server,node	UserScriptAfterSessionFailure	session id, username, node host, node port	session id, username, session type, display
server	UserScriptBeforeCreateUser	username	-
server	UserScriptAfterCreateUser	username	-
server	UserScriptBeforeDeleteUser	username	-
server	UserScriptAfterDeleteUser	username	-
server	UserScriptBeforeEnableUser	username	-
server	UserScriptAfterEnableUser	username	-
server	UserScriptBeforeDisableUser	username	-
server	UserScriptAfterDisableUser	username	-

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.

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

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 NoMachine Enterprise Desktop is a node of a Cloud Server, consider that custom scripts have to be placed in server.cfg or node.cfg file on the Enterprise Desktop host, not on the Cloud Server.

12. Connections to the Remote Desktop and Collaborative Sessions

By default all users can connect to the remote physical desktop of the Enterprise Desktop host. When the desktop owner is different to the connecting user, he/she is always required to authorize the incoming request for connection unless the incoming user is a system administrators, a NoMachine administrator or a NoMachine trusted user.

Authorization is not requested when the incoming user and the desktop owner are the same. This can be configured via the UI in Settings -> Server -> Security panel. More configuration aptions are available via the server.cfg settings, see the paragraph in this guide about 'Managing Desktop Owner's Authorization'.

Other features like blanking of the remote screen and automatic lock of the remote screen upon session disconnection, configuring interactive/view-only mode and forcing a system logout upon session disconnection are also available. See the related paragraphs in this guide.

When users connect to unattended or headless machines, consider disabling the request for desktop owner's authorization before connecting or make such users trusted.

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.

12.1. Blanking the Remote Screen and Auto Lock Upon Disconnecting

NoMachine Enterprise Desktop supports 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 Enterprise Desktop host machine
from the UI:
in the Settings -> Server -> Security panel select the 'Blank the physical screen when somebody connects' option

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

To disable screen blanking, set:
EnableScreenBlanking 0

Then restart the server to make this change effective.

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 by 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 UI
In the Settings -> Server -> Security panel by selecting 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.

12.2. 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'

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

In this way, the connected user will access the physical desktop in view-only mode.

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

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

When multiple users are connected to the desktop at the same time, it's possible to switch between interactive and view-only mode for a specific user. To do that, mouse click on the !M icon in the system tray, mouse over 'Connected users', mouse over a specific user, you can switch between 'Interactive mode' and 'View-only mode' for that user.

II. If Guest Desktop Sharing is enabled, you can use the Settings -> Server -> Security -> Only allow connections by guest users in view-only mode option to allow guests to interact or not with the remote desktop.

12.3. Forcing a System Logout Upon Session Disconnection

The system logout will be triggered by the execution of a script upon the closure of the NoMachine session. This script invokes the system command to force the logout, but due to great variety of supported systems, the script included in the Enterprise Desktop package provides by default just some most common examples. You will need to tune it according to your system.

This script, named forcelogout.sh, is placed under the NoMachine installation directory:
- /Applications/NoMachine.app/Contents/Frameworks/scripts/env/forcelogout.sh on macOS
- /usr/NX/scripts/env/forcelogout.sh on Linux
- %ProgramFiles(x86)%/NoMachine/scripts/env/forcelogout.bat on Windows

To force the system logout:
-edit the forcelogout.sh script and specify the command to logout, appropriate for your operating system.
-edit the server.cfg file and enable the following key:
LogoutOnDisconnect 1

When this key is enabled, NoMachine will try to execute the forcelogout.sh script. The automatic logout will be effective only if the command set in the forcelogout.sh script is appropriate.

If you need to execute the logout after a certain period of time, enable also the following key and specify a time value in seconds. The logout command will be executed when the timeout expires:
LogoutOnDisconnectTimeout 0
Timeout 0, the command to logout is executed immediately.

To delay the execution of the command, set the timeout in seconds. For example:
LogoutOnDisconnectTimeout 600
NoMachine will wait for ten minutes before executing the command to logout. If the user connects again by NoMachine in the meantime, the command to logout will not be executed.

Enterprise Desktop permits 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-ways copy and paste is fully supported in both traditional client and web client sessions. 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.

13.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 that). 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 the 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 UI
in the Settings -> Server -> Devices panel

or in the node configuration file
by editing the corresponding keys. The manual configuration permits also to limit only oneway of service, for example forbid to connect a local printer to remote. 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 relies on the NoMachine File-system Server (nxfsd) and NoMachine File-system Adapter driver on Windows. On Mac it uses the nxfuse extension whilst on Linux it uses FUSE, installed on the system by default. The nxfs and nxfsserver programs are used on all systems 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 relies on the NoMachine Device Server service and the NoMachine Printer Adapter driver on Windows. On Mac and Linux it uses the CUPS infrastructure present on the system. In this last case, 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 (NoMachine USB Hub, NoMachine USB Adapter and NoMachine USB Host Adapter on Windows, nxusb.ko kernel module for Linux and nxusb.kext up to macOS 11.x. ) 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 uses the NoMachine Device Server and the NoMachine VPN Adapter driver on Windows and Mac. On Linux it 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.

13.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.

For example on Mac you might edit the node configuration file and specify:
DiskSharingList $(HOME),/Volumes/TimeMachine

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:
/Volumes on Mac
/media on Linux
C:\Users\Public on Windows Vista/7/8/8.1/10/11

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

13.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 and Mac 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 local to their NoMachine session on Linux or Mac, it's necessary that the user already belongs to the CUPS System Group on the NoMachine server host. That's because, 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 and _lpadmin on Mac.

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

13.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 prevent users from being able to forward USB devices from the server to their own machine, set in the node configuration:
EnableUSBSharing client

13.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, it is necessary to 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

13.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 Readers 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

13.7. Copy and Paste Operations

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

You can disable copy&paste between client and server via UI in the Settings -> Server -> Security panel. Scroll it down to the 'Clipboard' section and uncheck the 'Allow clipboard functionality' option. If you keep that option enabled, you can also select from the menu on the right from which side the clipboard will be allowed.

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

Limiting copy & paste operations
To forbid copy & paste partially or totally, 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).

13.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, the file will be saved always on the desktop.

You can manage file transfer
from the UI
In the 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

14. Multimedia and Session Recording

Audio is fully supported in NoMachine sessions, but web sessions require to enable WebRTC. 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).

14.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.

On Windows 10,8,7 and Vista NoMachine's audio system perfectly integrates with the Windows media framework. On XP instead, NoMachine relies on its own driver, the NoMachine Audio Adapter. For microphone support NoMachine always uses the NoMachine Microphone Adapter driver.

On Mac, NoMachine installs and uses its own virtual drivers to support audio and microphone seamlessly.

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

Accepted values on Windows and Mac are instead 'nxaudio' or 'disabled'.

14.2. Recording the Screen

NoMachine allows recording a video of all activities made inside the session or on the 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 activities made on the desktop, start the recording from the !M icon menu in the system tray of the local desktop 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.

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 Desktop host, edit the node configuration to set:
EnableLocalRecording 0

By default the connecting user can accept or refuse to allow NoMachine to record his/her session. It's possible to change this behaviour by setting 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

14.3. Automatic Screen Recording

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 '.

15. Automatic Updates

The Enterprise Desktop, 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. Additionally, downloading a new software version in the background will not lead to an automatic update of the current installation.

A separate guide, available at: https://www.nomachine.com/all-documents deals specifically with all the possible options for the automatic software updates.

16. Logging Facilities

To retrieve logs by using the NoMachine tools, please refer to the 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.

16.1. Enabling NoMachine Log Rotation

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

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

On Linux and macOS:

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

and on Windows:

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

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

On Linux and macOS:

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

and on Windows:

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

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

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

Other commands to manage log rotation

List current settings for log rotation:

nxserver --logrotatelist

Edit parameters set for log rotation:

nxserver --logrotateedit LOG OPTION

Delete all settings for log rotation:

nxserver --logrotatedel

Delete log rotation settings for a specific log file:

nxserver --logrotatedel LOG

It's possible to force log rotation at any moment. This doesn't require 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:
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.

16.2. Using the System Logging Facilities

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

EnableSyslogSupport 1

Then restart the server and all services to make the change effective.

On Linux and macOS:

$ sudo /etc/NX/nxserver --restart

On Windows:

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

16.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

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

17. Setting-up Central Access to Multiple Enterprise Desktops

If you own multiple installations of Enterprise Desktop, 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 adding each Enterprise Desktop 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.

When added to the Cloud Server, the Enterprise Desktops 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 Desktop or, depending on the Cloud Server configuration, will be able to choose it manually. The Cloud Server is also able to automatically assign the first available Enterprise Desktop where nobody has connected yet.

When the Enterprise Desktop is part of a Cloud Server multi-node setup, by default it will no longer 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 NoMachine free cannot be part of a Cloud Server setup.

NoMachine Enterprise Desktop - Installation and Configuration Guide

Introduction

How to set-up the Enterprise Desktop

Connect to the Enterprise Desktop

Configurations and Optimizations

Enterprise Desktop's Administration

A Front-End to the Enterprise Desktops

Introduction

3.4. Connecting Without an Account (Guest Desktop Sharing)New!

Redirect clients on a per-IP basis

Redirect clients on a per-username basis

Other commands to manage log rotation

Automatic recording

File transfer logging

3.4. Connecting Without an Account (Guest Desktop Sharing)^New!