Two machines using same advertising information

[rlhatton]

I’ve got two computers running the same disk image with NoMachine pre-installed. In the device finder, I can only see one of them at a time (with the visible computer switching back and forth).

Looking at the NoMachine “Server settings” pane, I see that in addition to nx:// and ssh:// entries for their IP addresses on my network, both of the computers have an additional nx://  entry from a different range that is identical in both cases.

1. Is this extra nx:// entry causing the systems to advertise themselves using identical information?

2. If so, how do I change things to prevent this from happening? I don’t see any way to actually edit any of the settings.

(The machines I’m connecting to are headless and running Ubuntu, my client is on a Mac.)

[fra81]

Hi,

since the two machines are clones, I assume that they share the same uuid. You should execute the following in one of them:

sudo /usr/NX/bin/nxserver --shutdown
sudo rm -f /usr/NX/etc/uuid
sudo /usr/NX/bin/nxserver --startup

[rlhatton]

Executing those commands does result in the systems distinguishing themselves in the NoMachine main pane.

Unfortunately, it also results in connection attempts failing after the password with “The session negotiation failed.”

Is there something else I need to do as well?

[fra81]

Were you connecting successfully before updating the uuid?

In order to know what’s going on, we would need to see the server side logs. You can find instructions in https://knowledgebase.nomachine.com/DT11R00182. You can send collected logs to forum@nomachine.com, by referencing this thread.

[rlhatton]

Yes:

1. On a clean instantiation of the cloned system, I can successfully connect via NoMachine.

2. If I execute the first and third commands you suggested, it brings down the NoMachine interface and then brings it back up with

NX> 111 New connections to NoMachine server are enabled.
NX> 161 Enabled service: nxserver.
NX> 161 Enabled service: nxnode.
NX> 161 Enabled service: nxd.

(and I can use NoMachine to connect to the system)

3. If I remove the uuid file between executing the nxserver commands (I’m now using sudo mv instead of sudo rm to keep the original file on hand), then nxnode is not brought back online:

ubuntu@ubuntu:/usr/NX/etc$ sudo /usr/NX/bin/nxserver --shutdown
NX> 162 Disabled service: nxserver.
NX> 162 Disabled service: nxnode.
NX> 162 Disabled service: nxd.
ubuntu@ubuntu:/usr/NX/etc$ sudo mv uuid uuid.backup
ubuntu@ubuntu:/usr/NX/etc$ sudo /usr/NX/bin/nxserver --startup
NX> 111 New connections to NoMachine server are enabled.
NX> 161 Enabled service: nxserver.
NX> 162 Disabled service: nxnode.
NX> 161 Enabled service: nxd.

4. Returning the system to the original uuid as

ubuntu@ubuntu:/usr/NX/etc$ sudo /usr/NX/bin/nxserver --shutdown
NX> 162 Disabled service: nxserver.
NX> 162 Service: nxnode already disabled.
NX> 162 Disabled service: nxd.
ubuntu@ubuntu:/usr/NX/etc$ sudo mv uuid.backup uuid
ubuntu@ubuntu:/usr/NX/etc$ sudo /usr/NX/bin/nxserver --startup
NX> 111 New connections to NoMachine server are enabled.
NX> 161 Enabled service: nxserver.
NX> 161 Enabled service: nxnode.
NX> 161 Enabled service: nxd.

again allows me to connect to the system.

4. My best guess is that the new UUID created when the –startup command is executed and the uuid file does not exist does not propagate into the files associated with nxnode, and that this then causes session negotiation to fail. In support of this guess, I note that searching the /usr/NX/etc/ directory for the original UUID returns many results,

ubuntu@ubuntu:/usr/NX/etc$ sudo grep -R fe8e1d57-82a9-41e9-bdd6-03dab868cf8a .
Binary file ./temp-2311.rdb matches
Binary file ./temp-2419.rdb matches
Binary file ./core matches
Binary file ./temp-2302.rdb matches
Binary file ./temp-2402.rdb matches
Binary file ./temp-2447.rdb matches
Binary file ./temp-2301.rdb matches
Binary file ./temp-4650.rdb matches
Binary file ./temp-5805.rdb matches
Binary file ./temp-2438.rdb matches
Binary file ./temp-2943.rdb matches
./uuid.backup:fe8e1d57-82a9-41e9-bdd6-03dab868cf8a
Binary file ./temp-2484.rdb matches
Binary file ./temp-2709.rdb matches
Binary file ./temp-27735.rdb matches
Binary file ./temp-5002.rdb matches
Binary file ./temp-2296.rdb matches
Binary file ./temp-2329.rdb matches
Binary file ./nxdb matches
Binary file ./temp-3556.rdb matches

but that searching for the new UUID string only returns the new uuid file,

ubuntu@ubuntu:/usr/NX/etc$ sudo grep -R 2cd1e6ce-ea84-44bf-9601-ced7deea089c .
./uuid:2cd1e6ce-ea84-44bf-9601-ced7deea089c

(I have emailed you the logs)

[og00r]

So there is now TR for it:
https://knowledgebase.nomachine.com/TR01T10426

but in meantime you could run:
sudo /etc/NX/nxserver –shutdown
sudo mv uuid uuid.backup
sudo mv nxdb nxdb.backup
sudo /etc/NX/nxserver –addtoredis
sudo /etc/NX/nxserver –startup

It should help you 😉

[rlhatton]

Thank you. I tried the suggested commands, but they still did not work. Same errors appeared.

[og00r]

Can you please send us the nxdb file from /usr/NX/etc/ directory to forum[at]nomachine[dot]com, referencing the topic as subject ?

Please also tell us if the new nxdb file is generated after --addtoredis command or after --startup command? (you could easily re-do it if you are not sure)

[Author]

Posts