Mth

[Mth]

Hello

There are not any known outstanding problems with access to Login Window on CentOS with gdm right now. The worst case would be if it was virtual machine and login window running on Wayland. In this case I would suggest disabling Wayland.

If there are no warnings/errors generated in the nxserver.log file this may be either something in the configuration or with the xserver.

The configuration thing to check would be:

sudo /etc/NX/nxserver --userlist

The entries there should show if any user has “Screen sharing” or “Access” disabled. If the user “gdm” has this disabled it may prevent anyone from seeing Login Window session.

If there is nothing helpful there, please gather logs and send them to us. Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --restart

and reproduce the problem when user does not see the Login Window session. Please gather the 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.

Also what method are you using for logging out the inactive user? Any native method or some script?

/Mth

[Mth]

Hello

This is an ongoing issue for MacOS 10.15.16. There is a known problem on login window where the process responsible for grabbing session is started before the session is
properly initialized. Until there is a new version released it is a possibility to fixing this by logging via ssh and manually restarting the nxserver:

/etc/NX/nxserver --restart

If this does not help we would need to do some more debugging of this case.

/Mth

[Mth]

Hello.

First two questions:

1. Have you installed the new version from the desktop, or using command line? If from the desktop, has the user the administrator privileges?

2. After installation were you prompted with accessibility questions?

I am afraid this is something new that was introduced with the Catalina 10.15.6 update and has nothing to do with the accessibility any more, but we still need some data to
handle this.

Could you please follow this:

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.

At this point for further investigation would be great to enable the logs in both server.cfg and node.cfg on the server machine. Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --startup

and accept any requests for permissions from the operating system.

If the issue should persist after this, it would at least rule out any older bug being not fixed.
In this case please gather the 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.

Unfortunately the fix for this problems was delayed and we did not manage to include it to the 6.11.2 release. It should be available in the next one.

/Mth

[Mth]

Hello

The error 108 with the context of the connection to physical desktop looks very strange. I’m afraid that we would require full logs to see what is going on here.

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

And then please connect again to reproduce the problem. 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.

And some question to clarify.

1. The error happens before entering the credentials, or after?
2. Are there any crash reports regarding nxnode or nxserver processes in the system. If yes, please send us the backtrace.
3. Is the machine in Login Window or desktop state. If on desktop, is there any screen saver/screen lock mechanisms enabled. Is Wayland enabled on both login window and desktop?

/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

[Author]

Posts