Cannot connect to remote Linux server running NoMachine

Forum / NoMachine for Linux / Cannot connect to remote Linux server running NoMachine

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #36635

    I am having two remote servers, both running Archlinux and NoMachine. Since couple hours, I can not connect to them – I get the following error message:

    “The remote host ‘’ refused to establish a network connection on port ‘4000’. Please verify that NoMachine is correctly installed and listening on the port where you are trying to connect, and that incoming traffic is not being blocked by a firewall or NAT.”

    The servers are up and running, I can both ping and ssh into them.

    When I run the commands status/restart through SSH, I get the following messages on the server:

    sudo /etc/NX/nxserver –status

    NX> 111 NoMachine server has been shut down.
    NX> 162 Disabled service: nxserver.
    NX> 162 Disabled service: nxnode.
    NX> 162 Disabled service: nxd.

    sudo /etc/NX/nxserver –restart

    NX> 162 Service: nxserver already disabled.
    NX> 162 Service: nxnode already disabled.
    NX> 162 Service: nxd already disabled.

    I already restarted one of the servers, but it did not help.
    Can you please advise, how can I fix this issue? It triggered on both remote servers simultaneously, at the same time.

    Below some extra information.

    Thank you!

    Local NoMachine product & version: 6.16.1 (free)
    Server NoMachine product & version: 7.7.4-1 (free)

    Connecting to remote server (no physical display)

    Local OS: Linux Mint 20.2
    Server OS: Archlinux (Kernel: 5.15.7-arch1-1)

    Local desktop version: Xfce/Xfwm4
    Server desktop version: LXDE/Openbox


    There’s something wrong with your configuration maybe? Try removing completely and install again.

    sudo /usr/NX/scripts/setup/nxserver –uninstall && sudo rm -rf /usr/NX /etc/NX /var/NX .nx

    We don’t actually support Arch but we did check on the fly. Since Arch is a rolling release and it’s possible that a new system update might have broken something, we downloaded it to make sure, and installed it with the same set up as you, and were able to connect.


    Unfortunately I was not able to fix this with reinstalling NoMachine, so I did reinstall the entire OS from scratch and installed NoMachine freshly and it works fine.

    Although I am having a new issue, with this newly installed config: previously I was able to set practically any display resolution for the remote server, but now the maximum available, selectable display resolution is a low value and can not change it to match the client resolution. I am going to post this as a separate thread, to ask for some further help.


    so I did reinstall the entire OS from scratch and installed NoMachine freshly and it works fine.


    So it seems something was not quite right with your Arch install.  Thanks for letting us know.


    previously I was able to set practically any display resolution for the remote server

    You will find some useful tips and information here:

    Some tips about resize and scaling options for NoMachine


    I have checked the resizing/scaling related documentation, but I did not find a solution for my problem.

    The problem:

    After newly installing the server and NoMachine, the NoMachine connection works fine, but I can not set the proper screen resolution for the server. It is a cloud/headless server, and previously this was not an issue, although now the max resolution seems locked and no matter how/what I change, I can not achieve the desired resolution to match the client screen (2560 x 1440).

    It is strange, because when I connect to the server using xrdp, I can set any screen resolutions, including the desired 2560 x 1440.

    The same issue exists on freshly installed Ubuntu and Arch cloud servers as well.

    Can you please advise? I would like to keep using NoMachine, because xrdp connection is dead slow.



    What I see here is the issue with your xorg Display configuration of the headless server, that needs to be adapted to use higher display resolutions.
    NoMachine when connecting to the physical screen uses only provided resolution from the system, and as you show on your screenshots that was 1366×768.
    If you want that NoMachine set up screen resolution, you could use NoMachine workstation virtual desktops, or ask NoMachine to create physical display for you. More info about mentioned feature can be found here: FR10L02842 – Giving the possibility to connect a physical session in NoMachine free version when the local X server can’t be found.


    Thank you very much, the linked article’s instructions solved the problem.

    Enabled CreateDisplay 1 and set DisplayGeometry in the server.cfg and when I connect, the proper resolution comes up by default.



    I am really happy that my post helped you.


    May I ask for further assistance?

    The above mentioned solution (edit server.cfg) worked until now, but after rebooting the server, the max resolution is locked to 1366×768 again.

    After a fresh server reboot, when connecting with NoMachine, I am provided by the Lightdm login screen, then after the login, the previous lower resolution is available only, no matter what I set in the cfg file or in the client.

    I double-checked the server.cfg file and it still uses the settings, I manually set based on your instruction.

    I am not sure, but it seems, like lightdm (?) overrides the NoMachine server settings and does not allow NoMachine to create the display.

    Before the restart, after clicking connect with the NoMachine client, I was provided by two options: to connect to ‘Display 10’ or Display 0. When I selected the first option, NoMachine connected with the proper 2560×1440 resolution.

    Now, after the restart, I do not have any options in the NoMachine client to select from, but it connects straight to the lightdm login screen of the server where I have to enter my password (strange because I saved it in the client).

    Any advice would be greatly appreciated!


    If it is headless machine I would disable lightdm to start on boot, you can do that by executing
    systemctl disable lightdm.service and then reboot machine.

Viewing 10 posts - 1 through 10 (of 10 total)

This topic was marked as solved, you can't post.