Mth

[Mth]

Hello

The topic and trouble report you found is a bug that was happening only for NoMachine version 6.7.6, so it should not be the case here.

The most probable cause here is an update from a non-administrator account. We have tested this scenario on previous versions, and indeed the result was the “no physical desktop” screen. What the tests also showed was that a simple machine restart would fix the problem and the connections was possible again.

Of course this may not be the case here, so let’s start with a restart. Then if the problem still persists please do:

sudo /etc/NX/nxserver --shutdown

Then navigate the OSX options to the “Security and Privacy”, the “Privacy” tab and from both “Accessibility” and “Screen recording” options please remove (by clicking ‘-‘ button, not just by disabling the checkbox) any and all “NoMachine”, “nxnode” or “nxserver” entries. then please do:

sudo /etc/NX/nxserver --startup

and accept any requests for permissions.

/Mth

[Mth]

Hello

Thank you for the logs and information.

It seems that on Login Window you still have the Wayland enabled, and
for unknown reasons we are detecting it as a desktop, so this will need a fix
from our side.

For now you can try disabling the Wayland from the login window too,
desktop and login window has different configurations.

/Mth

[Mth]

Hello.

As I wrote before, as there was not enough information to make any reasonable guess, this is how this key is supposed to work.

With what you provided it is clear that there is something wrong. For one you should never be asked for “desktop user to authorize your connection” on login window.

As for the logs, I doubt there will be anything important on the default debug level, as when the NoMachine detects the physical session, unless some error happens there is no reason (yet) to disbelieve what was detected.

So we would require some additional information to help debug this problem. I see the operating system in logs (Ubuntu 20.04 LTS), but which desktop environment and desktop manager are being used? Is it a physical machine or a virtual? Is Wayland being used for login window or/and desktop? If it is a physical machine is there a monitor (or multiple) connected or is it a headless system?

And as I mentioned, we need to increase the debug level to see what is happening in more detail. If you are willing to help us further 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

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

/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

[Author]

Posts