NoMachine Not Working — A Troubleshooting Guide
If you encounter errors like NoMachine doesn’t connect or NoMachine connection refused, their support funnel requires customers to send a message directly to tech support, or describe the issue on their forum. From there, customers are provided with several solutions:
- • Set debug log level manually
- • Reproduce the problem
- • Create the compressed archives of logs
- • Send the archives to NoMachine Support Team via e-mail
- • Request NM Support provide a place to upload logs if file sizes exceed what can send as an e-mail attachment
This can take a while, but makes it much easier to define the most effective way to resolve the issue. To expedite a NoMachine not connecting solution (and more) before reaching out to IT support, check out a few of the following self-service methods provided in this article. We also suggest you read the NoMachine vs. RealVNC comparison article, as well as the NoMachine vs. TeamViewer comparison.
Error 107: NoMachine Connection Refused
Along with the other issues (like NX NoMachine session failed or NoMachine no monitor) Error 107 most often means the client-side of the connection isn’t able to access NoMachine’s service (which is located on the remote host.) Follow the steps below to try correcting this without involving NM support.
Method 1: Make sure the correct IP and Port are set correctly (Do this on NoMachine’s User Interface by opening Server Preferences > Services tab while operating the host that needs access permission).
Method 2: Ensure firewall configurations on the server and client machines aren’t causing the problem (usually firewalls aren’t the root issue if it’s native to the operating system being used).
Method 3: Review the nxserver status on the server machine (Do this by opening the Server Preferences (Server Preferences > Services tab) and ensuring status is set to ‘Running’).
How to open NoMachine ‘Server Preferences’
Users may need to access the GUI (Graphical User Interface) to manage the server and configure custom settings. There are two ways to accomplish this:
- • Step 1: On the system tray, click the “!M” icon to open the menu
- • Step 2: Click Show the service status > Server preferences
- • Step 1: Run NoMachine from your program menu
- • Step 2: Click Settings > Server preferences (a link located in the bottom panel)
Note: NoMachine’s Server preferences UI (User Interface) consists of six tabs to transfer the available configuration panels: Services, Security, Devices, Transfers, Performance, and Updates.
“NoMachine authentication failed, please try again” Error
Step 1: First ensure the connection is reaching the intended machine (the one located at a workplace, for example).
Step 2: Examine the nxd.log file to check for any info regarding incoming connections (during the attempted connection) is the only way to accomplish this.
Step 3: If there’s no incoming connection, configure access to the appropriate machine via setting up a firewall or NAT router.
If NoMachine (server) computers are behind a firewall or NAT router, NoMachine attempts to use protocols UPnP or NAT-PMP (based on what the router supports).
It does this to:
- • Retrieve the host’s public or external IP
- • Set up routers to permit NoMachine clients to connect from beyond the private network
All types of servers support the UPnP/NAT-PMP port mapping, but only personal/small environment products enable it by default.
UPnP/NAT-PMP port mapping enabled by default:
- • NoMachine Free Edition
- • NoMachine Workstation
- • NoMachine Small Business Server
UPnP/NAT-PMP port mapping disabled by default:
- • NoMachine Enterprise Desktop
- • NoMachine Terminal Server
- • NoMachine Enterprise Terminal Server
- • NoMachine Cloud Server
- • NoMachine Enterprise Server v. 5 and 4.
How it resolves potential issues:
UPnP or NAT-PMP port mapping services only function when:
- • It’s enabled within the server configuration
- • The router offers UPnP or NAT – PMP support
- • UPnP or NAT-PMP is enabled
- • The router accepts UPnP — or NAT-PMP commands to allow port forwarding
Regarding point 4 (“The router accepts UPnP or NAT-PMP commands to allow for enabling port forwarding”).
If the router won’t support UPnP or NAT-PMP commands, users must manually set it up via the administrative interface.
Those using the free edition of NoMachine must open port 4000 on the router, then map it to the public IP address of the NoMachine (server) host.
The ports that must be opened and mapped to public IP addresses on the host are:
- • 4000 for connections using the NX protocol
- • 22 or 4022 on Windows for connections using the SSH protocol
- • 4080 and 4443 for web connections
Note: The default port values are editable via server admin UI on NoMachine.
Step 1: From the system tray, click the “!M” icon to open the menu.
Step 2: Select ‘Show the service status’ (‘Connections’ or ‘ Server status’ via versions 5 and 4).
Step 3: Open ‘Server preferences’ (previously referred to as ‘Connection preferences’ on the free version of NoMachine versions 5 and 4).
Step 4: Open the Services panel.
Enabling UPnP/NAT-PMP port mapping
NoMachine Free Edition users must edit their server configuration file (namely server.cfg) and set:
Step 1: Enable UPnP NX for users connecting with the NX protocol
Step 2: Restart NoMachine
How users can configure this via the UI on the server’ machine:
Step 1: From the system tray, click the “!M” icon
Step 2: Select ‘Show the service status’
Step 3: Hit the ‘Restart the server’ button
The following options are available on NoMachine subscriptions:
EnableUPnP NX: For those connecting with the NX protocol
EnableUPnP SSH: For users connecting to the SSH protocol
EnableUPnP HTTP: Regarding web connections scenarios
How to disable UPnP/NAT-PMP port mapping:
Step 1: From the server configuration file (server.cfg) set: “EnableUPnP none”
Step 2: Restart NoMachine
Server connections are still possible — but only if server hosts (and end-user pc/devices) share the same local LAN — or if the server uses a public IP address.
How to Locate the server.cfg file
The configuration files for the server (server.cfg) are displayed below. For those using version 5 and under, if they have Cloud Server installed, their web players also provide a configuration file (“cloud.cfg.”)
From versions 6 and on, web session keys are included in server.cfg—and the cloud.cfg file is gone.
Configuration files are kept in the ‘etc’ directory, under NoMachine’s installation directory:
/usr/NX/etc/server.cfg on Linux
InstallationDirectory/NoMachine/etc/server.cfg on Windows
(e.g. C:\Program files (x86)\NoMachine\etc\server.cfg)
/Applications/NoMachine.app/Contents/Frameworks/etc/server.cfg on Mac.
NoMachine No Audio Troubleshooting Solutions
What to do if audio is missing in a NoMachine session:
- Step 1: Download PulseAudio Volume Control.
- Step 2: Run PulseAudio Volume Control.
- Step 3: Navigate to “Output Devices”.
- Step 4: Click the “Set as fallback” (a green button beside the built-in Audio Analog Stereo).
- Step 5: Increase the sound level.
Missing audio—NoMachine audio devices are not available:
If there’s still no audio after using PulseAudio Volume Control to increase, check whether NoMachine audio devices are actually available on the system.
Execute the following in a terminal:
pactl list sources | grep NoMachine
pactl list sources | grep nx
If the list is empty, users can recreate NoMachine sinks and sources by doing the following:
Step 1: End the PulseAudio process (this automatically creates a new process)
Execute in a terminal:
Step 2: Restart the NoMachine server.
Execute in a terminal:
sudo /etc/NX/nxserver --restart
NoMachine Error: NoMachine Cannot Create a New Display/Negotiation Failed
If Linux users receive the following message when attempting to connect with a Linux host:
“The session negotiation failed. Error: Session failed, application terminated prematurely.”
… this can mean that programs/apps run by the NoMachine node (i.e. the desktop environment or a custom application) end immediately after initiating.
This can occur when the command that launches the desktop (or the custom app) is inaccurate.
The command that starts a Linux desktop environment is defined in the DefaultDesktopCommand key—within the node configuration file (“/usr/NX/etc/node.cfg.”)
For example: DefaultDesktopCommand “/etc/X11/Xsession ‘gnome-session –session=ubuntu'”
To check if the command is accurate, perform the following:
Step 1: Figure out which desktop environment is installed on a system by executing the following terminal command:
Step 2: Retrieve the command to run the desired desktop. The command is shown in the *.desktop file in the line beginning with “Exec.”
grep ^Exec /usr/share/xsessions/gnome.desktop
Step 3: After retrieving the command, check that it’s set in the DefaultDesktopCommand key in node.cfge:
Users don’t need to restart the server because the changes go into effect as soon as the new session starts.
Regarding custom sessions, the application running the node is specified within the UI of the client. For example: ‘Run the console‘ or the app set in ‘Run the following command‘.
When the program/software ends immediately, the following error gets reported inside the connection log file:
NX> 501 Session failed, application terminated prematurely
NX> 598 Error: failed to connect to nxclient –monitor.
On the end user’s host, the session log file reflects as follows:
3579 3579 15:18:18 658.862 ClientSession: Failing reason is ‘The session negotiation failed. Error: Session failed, application terminated prematurely.’
These error files are located in the NoMachine session directory, which is created in the /usr/NX/var/log/node directory.
When the error ‘application terminated prematurely‘ displays, it’s helpful to find possible causes in the below files (located on the remote host):
Number 1: The clients file within the: /usr/NX/var/log/node/C-<session> directory
Note: NoMachine’s node redirects the standard error of X app to this file.
When a virtual desktop is running, however, consider that the X display manager commonly redirects the standard error to: “~/.xsession-errors” and NoMachine’s client file can be empty.
Number 2: The .xsession-errors file in the user’s home
For example: /home/nxtest01/.xsession-errors
Number 3: The system log
For example: /var/log/messages on Ubuntu
or, if the operating system is systemd-based: journalctl -b -0 > journalctl.txt
Number 4: The following test may also offer more information:
Step 1: Run a NoMachine custom session
Step 2: Choose ‘Run the console’ + ‘Run the command in a virtual desktop’
Step 3: Within this console, execute the same command set in the DefaultDesktopCommand key—within the node configuration file
NoMachine Cannot Change Resolution
Those using NoMachine free or Enterprise Desktop editions are connected to the remote computer’s physical desktop.
In this scenario, the maximum resolution available is the maximum resolution supported by the remote machine’s graphics card.
Linux remote hosts
For those needing to run a higher resolution, and it’s a Linux remote host, think about utilizing products that support virtual desktop functionality—such as NoMachine Workstation.
The virtual desktop’s supported resolution won’t depend on the remote hardware, thus the remote screen can be changed to whatever resolution is supported by the operator’s monitor.
Running at increased resolution is also possible via headless machines. In that circumstance, shut down the X server and allow NoMachine to create a virtual display.
NoMachine for Linux is intended to work out-of-the-box, regardless of the machine’s installed desktop environment. NoMachine can detect when X servers aren’t running, and so launch its own virtual display (an embedded X server.) This is enabled by default in the free edition and can be enabled in the commercial versions.
What to do if you see a black screen on Linux
This can happen when the X server is running but isn’t rendering due to the video card being turned off. In this scenario, NoMachine won’t use its own virtual display since it detects the X server running. There are few possible solutions:
Use a fake display dongle
Use a fake display dongle (also referred to as a ‘dummy dongle’) and insert it into the video card port to simulate the presence of a screen—thus forcing the system to take total advantage of the GPU as if a physical monitor was attached. For Linux hosts, rebooting the machine (or restarting the display manager) is required to make this work.
Setup Xorg for working in headless mode
2.1) Configure X.org to run headless (use –allow-empty-initial-configuration)
2.2) Install a Xorg dummy driver by creating a fake EDID (Extended Display Identification Data) and use it in Xorg.conf (EDID are kept in the monitor, and read out by the GPU when a monitor is attached)
Use an X virtual framebuffer
Users can try any of the methods above (or manually stop the X server) to force NoMachine to use its own display service:
- • Use the proper command to stop the X server based on your display manager. For example:
sudo systemctl stop lightdm
sudo systemctl stop gdm
sudo systemctl stop sddmand so on …
or, if you aren’t sure what it is, try a “display-manager” alias:
sudo systemctl stop display-manager
and restart the NoMachine server:
sudo /etc/NX/nxserver --restart
- • Now NoMachine will create its own virtual framebuffer, and users should now have the ability to connect and view the desktop.
Note: If a Linux system lacks systemd (e.g. RHEL 6 and earlier versions), restart the machine at runlevel 3:
sudo init 3
The first thing to do is verify whether the CentOS server IP is accessible from the Windows client.
If the answer is yes, ssh to the server and check on NoMachine’s server status using
sudo /etc/NX/nxserver --status.
If the server is off, try to restart the server with the command:
sudo /etc/NX/nxserver --restart