Mth

[Mth]

Hello

Thank you for reporting this. Indeed it is an abnormal behavior.
At first glance it seems this is caused by some leftovers in the system from previous installation. We have changed recently how this accessibility is handled and most probably it is not perfect yet.

Could you please provide more information that should help us understand what happened?

1. What OSX version do you have on this machine?
2. Is it a clean installation, or update. Even if it is not an update,
Maybe you had some another NoMachine version installed previously and
removed before installation? If yes, which version?
3. Was there any updates to osx itself recently?

The most likely workaround for this kind of issue would be to shutdown the NoMachine server:

/etc/NX/nxserver --shutdown

Then manually remove all accessibility rights (remove, not just disable):

1. From Screen Recording tab any “NoMachine” entry.
2. From Accessibility tab any “nxnode” and “NoMachine” entry.

Please check if they are not duplicated, if they are, also remove them and let us know that this happened too.

After removing it from the access rights, start up the server again:

/etc/NX/nxserver --startup

After this you should be asked again to grant NoMachine the access rights and this time they should be proper.

Let us know if this helped the situation.

/Mth

[Mth]

Hello.

Assuming that you are using the free version of NoMachine, not trial, just clean free,
by default the connection to physical desktop should be working like this:

1. When there is Login Window, you can connect with any user without prompt.

2. When there is user desktop logged, you can attach as the same user without prompt.
If you enter different credentials in NoMachine player, you are not desktop owner
and there could be a potential security risk involved, so you can only access when
someone accepts the connection.

The PhysicalDesktopAuthorization key should be a voluntary administrator decision
to let other accounts to access desktop, but only if different account is logged
to the desktop than the one used in NoMachine player.

There was not any change to this behaviour in a long time, so if it is not a case
of different accounts it could always be some bug with detecting session owner.

/Mth

[Mth]

Hello

Unfortunately we did not receive the logs, but it seems we would get a better view on this matter with debug enabled as this looks either like crashing vital process or server not starting at all.

First a few questions: did any update happen on the server machine between the time it was working and not working? Is any crash report generated when doing restart? Maybe it is simple result of lack of resources, like not enough space on hdd or ram issue?

It may be some simple answer to this, please check the “/usr/NX/var/log/nxerror.log” file, where the system errors should be outputted, if there is a simple reason it would be there.

If it’s nothing simple, please send us logs for investigation. Please refer to an article on how to enable debug:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Enable debug on the server machine and then do:

sudo /etc/NX/nxserver --restart

Then please gather logs either manually or by executing:

sudo /etc/NX/nxserver --debug --collect

If there is any crash report generated for nxserver or nxnode processes we would also be grateful for
backtrace.

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

A few questions:

Does this state persist? The physical session is on the remote machine and it can take some time between switching from login window context to user context. It can also take time for the gnome session to load. The rule of thumb here is everything more than 30 seconds is abnormal, but less could be still fine.

What happens if you terminate the connection and try again? Is there available session to connect, or empty list? Do you use the same user to connect via NoMachine as desktop owner?

Is this first connection true “Login window” or is it screen saver? gnome on newer Ubuntu has a nasty screen saver that starts on completely different seat than the physical session and the switch may be impossible – disconnecting and connecting again should help.

There is also always a possibility something is more broken here, so please send us the logs to help investigating.

The article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

There is one thing that come to mind. Please check if in the client --monitor options you have the “Lock the physical screen on disconnect” option selected.

On the server-side, i.e the computer you want to connect to, right click the system tray icon -> Show the service status -> Server preferences -> Security, last option on the bottom. If yes please turn it off, restart the nxserver:

sudo /etc/NX/nxserver --restart

and check if the problem is still happening.

If no, please provide logs so we can investigate.

The article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

Also please remember that after enabling logs as in the article you will have to restart the nxserver again and reproduce the problem.

Then you can use

sudo /etc/NX/nxserver --debug --collect

for NoMachine to automatically collect and pack the logs, or do it manually.

/Mth

[Mth]

Hello.

Perhaps the culprit here is the lock screen. On the remote host you are connecting to, please check if in the client –monitor options you have the “Lock the physical screen on disconnect” option selected.

Right click the system tray icon -> Show the service status -> Server preferences -> Security, last option on the bottom. If yes, please turn it off, restart the nxserver:

sudo /etc/NX/nxserver --restart

and check if it still is happening.

If it’s not checked, please provide logs so we can investigate.

The article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

About that “nxnode.bin[8648]: BUG in libdispatch client”, do you have a crash.report?
If yes, could you provide it with server logs?

The article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

For the white screen on physical desktop. Does the reboot / NoMachine restart you mention fix this? If yes there could be something interfering with the ability to
detect or mirror the display. It may be something running in the background – like virtual frame buffer – or the Wayland itself can cause troubles. Generally the
white screen on Wayland is connected with virtual machines or proprietary drivers, but it may happen in other circumstances. As graywolf wrote the reason should be
in the logs. You can find them in “session” files inside the /usr/NX/var/log/node/C-* directories. If having troubles please send them to us for investigation.

As for issue 2. Does it also happen on attach to physical desktop? Or is it virtual? Both of the issues may be connected, but there is also additional possibility.
Please check the server.cfg file and search for keys PhysicalDesktopMode and VirtualDesktopMode if they are uncommented and set to 0 this may be the cause.

It is possible that both of this issues are Wayland related so if it is possible, please check if there is any change in behavior when setting WaylandEnable=False.

In case you are willing to provide us with full logs, the article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable the debug and then do

/etc/NX/nxserver --restart

And then please reproduce the white screen and/or interaction problems.

Afterwards you can use the command

/etc/NX/nxserver --debug --collect

for NoMachine to automatically collect and pack the logs, or do it manually.

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

This is a strange behavior indeed, and should not be connected with the CentOS itself. There should be full compatibility between NoMachine
and RHEL-derived linux distributions.

There is not much clues from the errors you sent as what could be wrong here, but the most worrisome part is “Timeout of 10 seconds reached for terminating of node process”.
The closing of node process is usually matter of milliseconds, and this could mean that something hangs there. The frequent disconnects may be connected.

The main question would be what desktop environment and desktop manager are you using? Any other software that could interfere with X servers or file systems? Like working frame buffers, virtual machines, directory services etc.

“waiting for desktop user to authenticate the session” is a very specific message. It should only appear when the physical desktop user does not match the user you
authenticated as from the NoMachine player application. This may indicate something is running in the background that we mistake for the active session and has different user as owner. Or other underlying problem.

You can try to mitigate it by setting your account as NoMachine administrator. This should at least cause this desktop owner mismatch not to happen.
You can do it by running:

/etc/NX/nxserver --useredit <username> --administrator yes

In any case this looks like a problem for our developers to take care of.
Would you be willing to provide us with the full logs from the NoMachine?

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable the debug and then do

/etc/NX/nxserver --restart

You can use the command

/etc/NX/nxserver --debug --collect

after the restart for NoMachine to automatically collect and pack the logs.

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

If it worked before the update- something may have changed in the system that we were not able to handle. And the most probable thing here is the
update to gnome.

My question remains though. Do you run a headless physical session or make NoMachine to run desktop on virtual session.

If its the later, you probably need to update the DefaultDesktopCommand to what is right now used by the gnome.

If you run:

grep ^Exec /usr/share/xsessions/*.desktop

command You will get how the system is running installed desktop environments.

If you are running headless physical session, we need logs to check why it is not detected.

/Mth

[Mth]

Hello

As this is Amazon virtual machine it is probably headless from the start, so there might be a few issues associated with this.

Did you had to install Xserver and graphic environment manually or it came with it?
If you did install it afterwards, are you sure it is running? If yes – here is the problem, that NoMachine did not recognize it.

If no, the NoMachine will try to run the virtual session instead, but it need to be supplied with proper application path as to what to run.

Please check the node.cfg file for key DefaultDesktopCommand and see what is there, and make sure it points to the desktop environment
you installed. If it points to the generic Xsession script it may not be enough for operating system to run it.

If there is a physical session running and we did not recognize it, we will require the server logs for debugging. Please also note that very rarely after
installing the desktop environment the operating system requires restarting of NoMachine to be able to properly recognize the desktop.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable the debug and then do

/etc/NX/nxserver --restart

You can use the command

/etc/NX/nxserver --debug --collect

after the restart for NoMachine to automatically collect and pack the logs.

Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

It is still not clear why the authorization is failing.
We have:

ERROR!Authentication failed with error 7.

Which does not help as it is generic, authentication failed error.

To get the proper information, you need to check the system logs to see what happens during the authentication. Most common place to look
would be /var/log/auth.log file.

Entries to look for would include

pam_unix(nx:auth)

If  you are sure the other system authentication methods work, you can try using the ssh protocol to connect to the server.

From the player application you right click the connection, chose the “Edit” option and then change protocol to SSH. This will use the SSH authentication, so
the nx pam.d configuration will be ignored.

/Mth

[Mth]

Hello

From the logs you provided the reason seems to be here:

2020-03-10 13:03:06 012.355  8568 NXSERVER WARNING! Process 'c:\apps\nomachine\\bin\\nxexec --server --upnpstatus' with pid '9152/812' finished with exit code 1 after 0,015 seconds.

9152 1328 13:03:06 012 nxexecExecServer: ERROR! Only nxnode or nxserver can run --server command.
9152 1328 13:03:06 012 nxexecExecServer: ERROR! Cannot execute nxserver process.
Error code is : 0.^M
9152 1328 13:03:06 012 main: ERROR! Error: Server exec failed.

This is a bit of a puzzler, the path c:\apps\nomachine\\bin\\nxexec clearly exist, it is
clearly executed by nxserver, but the nxecec cannot recognize it.

The problem could be a result of bad installation, did you choose c:\apps\nomachine during the installation, or it was copied afterwards?

There is also a file ‘c:\ProgramData\NoMachine\nxserver\localhost\server.cfg’,
could you confirm that in this file a key “ServerRoot” is set up to point to the installation directory?

/Mth

[Mth]

Hello

The problem indeed is that the nxserver cannot open any socket to listen on. It should not be the fault on the NoMachine side,
at least not in normal circumstances. You should be able to find more clues in nxerror.log file – if the system reports a reason,
or in the operating system logs.

Please check if there is any clue to this within the Ubuntu logs, or the parent system logs – most probably it is because of how the chrooted system is set up, the parent OS is blocking any attempts to open a socket.

If there is nothing wrong in the system logs, please elaborate more about the system setup and how did you exactly set up the chroot environment.

We may need to reproduce the problem to handle it.

/Mth

[Mth]

Hello.

The logs shows that every instance of nxexec process is being blocked.
Most commonly there are problems with apparmor blocking the docker container.
We have a document on this topic:

https://www.nomachine.com/DT10O00161

Please check the troubleshooting part of that document.

There also can be a problem with the privileges on the container, sometimes
it is also required to add

--privileged

parameter to docker run command.

If the article does not help you, please check if there is anything in the system logs
of the parent operating system that could be relevant to starting any nx processes,
any access blocking, termination etc. Also please share the Dockerfile and the command
you use to start the container for us to debug.

/Mth

[Author]

Posts