Updated on March 25, 2024 in Troubleshooting

NoMachine Not Working — A Troubleshooting Guide

Helga York Article author

• HelpWire
• →
• Blog
• →
• NoMachine Not Working

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.

Useful tip:
For those who’d rather avoid the hassle of diagnosing and fixing issues, selecting a different remote support solution is advisable. HelpWire, a free and user-friendly substitute for NoMachine, provides a range of remote control functionalities for effective, immediate support of PCs, Macs, laptops, and workstations.

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:

Method 1

• • Step 1: On the system tray, click the “!M” icon to open the menu
• • Step 2: Click Show the service status > Server preferences

Method 2

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

Please note:
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.

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:

pulseaudio -k

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:

“ls /usr/share/xsessions”

Step 2: Retrieve the command to run the desired desktop. The command is shown in the *.desktop file in the line beginning with “Exec.”

For example:

grep ^Exec /usr/share/xsessions/gnome.desktop
returns:
Exec=gnome-session

Step 3: After retrieving the command, check that it’s set in the DefaultDesktopCommand key in node.cfge:

“DefaultDesktopCommand gnome-session”

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
For example:
“/usr/NX/var/log/node/C-testdrive2-1005-246612EE435B150D4A8D37463B948139/clients”

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
  or: sudo systemctl stop gdm
  or: sudo systemctl stop sddm and 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

Select a Flawless Substitute for NoMachine

Switch to a trusted substitute to Nomachine to save your time from fixing irritating problems. This on-demand remote support software you can use free of charge, making it one of the best Nomachine alternatives.

HelpWire is much more user-friendly and limitless when compared to Nomachine. It lets users provide quick assistance to clients without an extended setup procedure or digging too deeply into the settings.

Primary features: 

• • Cross-platform support;
• • Concurrent connections to multiple workstations;
• • Multi-monitor support;
• • Quick Connect;
• • Client management;
• • Built-in support chat.

Closing Thoughts

We sincerely hope that this article has assuaged any apprehensions you may have had about Nomachine issues. Equipped with a thorough set of solutions, you are now more adept and prepared to handle these challenges with efficacy.