fisherman

[fisherman]

Hi,

Based on the screenshot you shared from the NoMachine settings, it appears that the NoMachine server is not detecting the second display.

To investigate further, please run the following command on the server and share the output:
xrandr --query | grep " connected\| disconnected"

If two screens are listed as connected, please collect the NoMachine server-side logs and share them with us, following the instructions in this article:
https://kb.nomachine.com/DT07S00243

If only one screen is shown, there is likely an issue with the Xorg configuration. Since you mentioned that you are using a NoMachine workstation, one possible workaround is to log out from the physical desktop session and create a Virtual Desktop instead.

After creating the virtual desktop, please follow the steps in the article below—especially the section “Click on ‘Resize remote display’ then on ‘Fullscreen on all monitors’”:
https://knowledgebase.nomachine.com/AR06S01131

Please let us know the results or if you need further assistance.

[fisherman]

Based on this discussion and the info you shared, it looks like NoMachine is installed in two different locations: /usr/NX and /mnt/....

From the command output you posted:

sudo /usr/NX/scripts/setup/nxserver --update
NX> 704 NoMachine Server package is already installed in:
/mnt/library/Linux/NoMachine/nomachine_9.1.24_6_x86_64/NX.

We can see that there’s also an installation under
/mnt/library/Linux/NoMachine/nomachine_9.1.24_6_x86_64/NX/.
It also seems that this folder no longer exists or that the /mnt drive is detached, which explains the error message:
nawk: cannot open “/mnt/library/Linux/NoMachine/nomachine_9.1.24_6_x86_64/NX/etc/server.cfg”

As a workaround, you can try copying the files from /usr/NX/ to /mnt/library/Linux/NoMachine/nomachine_9.1.24_6_x86_64/NX/, and then run:
/mnt/library/Linux/NoMachine/nomachine_9.1.24_6_x86_64/NX/scripts/setup/nxserver --uninstall

This should let you properly uninstall the leftover NoMachine installation.

[fisherman]

After restoring, you can run sudo /etc/NX/nxserver --uuidset.
This will generate a new UUID for the host.

[fisherman]

Hi,

By default, NoMachine version 9 uses an RSA key pair with a 2048-bit length. You can manually configure it to use 4096-bit RSA keys instead.

Additionally, NoMachine is evaluating using ECDSA keys as the default option in future releases.

Regards,

[fisherman]

Configuration save/restore is described in this KB article https://kb.nomachine.com/AR05T01160. In short, it is possible to restore the configuration on a different machine without issue.

Important note:
If you intend to run both hosts simultaneously, you must change the UUID of the restored machine to avoid conflicts.

[fisherman]

Hi,

Apologize that I have missed your response.

To clarify, there’s no need for the node administrators to manually copy or share SSL certificate files when the certificate for nxd is changed.

As you mentioned (or I understood), the nodes are managed by different administrators who will generate new certificates

After the new certificate is generated on the node, ECS Admin, instead of managing certificates manually, will run the following command:
sudo /etc/NX/nxserver --nodeedit <NODE_NAME>

This command connects to the node, detects the SSL certificate mismatch, and prompts whether to accept the new certificate. Once confirmed, the certificate is automatically updated. There is no need to exchange or distribute cert files manually.

[fisherman]

To replace node certificates, please follow this article:
https://kb.nomachine.com/DT07S00229#7

LD_LIBRARY_PATH=/usr/NX/lib/ /usr/NX/bin/nxkeygen -k /usr/NX/etc/keys/node.localhost.id_rsa -p /usr/NX/etc/keys/node.localhost.id_rsa.pub -t rsa -n 4096

And then, based on the direct or inverse node, do the same as mentioned in previous post:

#1. On the node
scp $ECS_IP:/usr/NX/etc/keys/host/node.localhost.id_rsa.pub $ECS_IP_node.localhost.id_rsa.pub
sudo /etc/NX/nxserver --keyadd $ECS_IP_node.localhost.id_rsa.pub

#2. On ECS
sudo /etc/NX/nxserver --nodedit #NODE_NAME

[fisherman]

Hi,

If I understood your goal correctly, you’re looking to add a node to ECS without requiring password authentication. You can achieve this by following the steps below:

To add a node to ECS
#1. On the node
scp $ECS_IP:/usr/NX/etc/keys/host/node.localhost.id_rsa.pub $ECS_IP_node.localhost.id_rsa.pub
sudo /etc/NX/nxserver --keyadd $ECS_IP_node.localhost.id_rsa.pub

#2. On ECS
sudo /etc/NX/nxserver --nodeadd $NODE_IP --node-name $NODE_NAME

To perform the reverse ( adding an inverse node to an ECS )

Follow the same procedure, but switch the roles:
– Run step #1 on the ECS
– Run step #2 on the node

Would you need help to make the script for this flow?

[fisherman]

Hi

What I can recommend is to use NoMachine commands and execute the following:

1. on ECS1: sudo /etc/NX/nxserver --configsave
2. Then copy the saved configuration to the ECS2
3. on ECS2: sudo /etc/NX/nxserver --configrestore

This will restore the UUID of the ECS1 to ECS2, and as I noticed in my test, all will work correctly.

To keep UUID unique, I would recommend that you same UUID on ECS2 before running restore.
– before step #3 run: sudo /etc/NX/nxserver --uuidget
– after step #3 run: sudo /etc/NX/nxserver --uuidset $UUID_ECS2

[fisherman]

Hi Steve,

I’m not entirely sure I fully understood your request, but it sounds like you’re trying to set up a flow that will either automatically create or reconnect to a session in order to verify whether the server is functioning correctly.

If that’s the case, you could try the following on ECS:
– Run /etc/NX/nxserver --nodelist to check that all nodes are listed and running.
– Or, run /etc/NX/nxserver --status directly on the node to verify that all NoMachine services are operational.

Additionally, you might consider using a preconfigured .nxs file with NoMachine Player to connect and check the session status automatically. There’s some useful guidance on this approach available here:
https://kb.nomachine.com/AR02P00963

Let me know if this helps or if I misunderstood the intent behind your request.

[fisherman]

Hi,
Since the session types appear to be correctly defined in the configuration files, could you check whether any propagation rules on the cloud server might be restricting certain users from accessing specific session types?

[fisherman]

Hi,

$ sudo /etc/NX/nxserver –nodedel Machine-01 –force –node-group node_grp_01
NX> 500 ERROR: Cannot remove node from node group ‘node_grp_01’.
NX> 500 ERROR: Node is not part of node group ‘node_grp_01’.

The message means that Machine-01 cannot be removed from node_grp_01 because it is not currently a member of that node group.

[fisherman]

Hi,

Basically, what I see from the install logs nx user requires the following rights:

• SeServiceLogonRight – Log on as a service
• SeDenyInteractiveLogonRight – Deny log on locally
• SeTcbPrivilege – Act as part of the operating system
• SeAssignPrimaryTokenPrivilege – Replace a process level token
• SeIncreaseQuotaPrivilege         – Adjust memory quotas for a process

[fisherman]

Only thing that I could think of is not something with a hyphen type sudo /etc/NX/nxserver --nodegroupdel Nodes_Group_01.

Based on the copy of the output you did looks like the first “-” is longer than expected.
NX> 500 ERROR: Invalid command: '–-nodegroupdel'

[fisherman]

Hi,

in your case, you should use it like following
sudo /etc/NX/nxserver --ruledel --class node --type Nodes_Group_01 --group USERS_GROUP_01
sudo /etc/NX/nxserver --ruledel --class node --type Nodes_Group_01 --system

[Author]

Posts