Britgirl

[Britgirl]

bsammon, we have received your logs.

[Britgirl]

Check the topic here which was related to Firewalld. Not specifically for Arch but it might help?

No external IP

[Britgirl]

We are still investigating but so far the error appears to be caused by dbus not returning the proper connector name for the monitor when it’s locked and put into sleep status. This then causes the issue that you are encountering and the user is unable to connect. We’ll come back to you when we have further information.

[Britgirl]

I also installed NoMachine on iPad but neither PC nor RPi can be connected.

Please confirm so that we can investigate:

– All the devices are on the same LAN and are visible in your Machines panel. If so, and you can’t connect, what errors do you see?
– Or are you connecting using the IP addresses? If so, and you can’t connect, what errors do you see?

Confirm the following:

– From Mac you can connect to Windows
– From Mac you can connect to Raspberry

– From Raspberry you can connect to Windows
– From Raspberry you can see and connect to Mac

– From Windows you can connect to Mac
– From Windows you can connect to Raspberry

– From iPad you cannot connect to Windows – what’s the error?
– From iPad you cannot connect to Raspberry -what’s the error?
– From iPad you can connect to Mac

[Britgirl]

NoMachine is designed to work out-of-the-box on Linux headless machines and NoMachine is able to detect when the X server is not running and run its own virtual display, which is an embedded X server. Turning off the monitor on Linux, when before it was switched on (so you force it to become headless), can lead to various symptoms (e.g. black screen or white screen or frozen screen), so you should stop the X server manually first, in order to make NoMachine use its own display service. That way when you get home and connect, you will not see a black screen. Instructions on how to do this are in this article help: https://kb.nomachine.com/AR03P00973.

[Britgirl]

Hi, please check your command formatting. The correct command to use is xrandr --listmonitors.

[Britgirl]

The issue is possibly related to the following Trouble Report already open and being investigated: https://kb.nomachine.com/TR03V11103. Please use the link to track its status.

[Britgirl]

I forgot to mention that version 8.16 was released last month (I noticed you are using 8.13), so if possible you should update your installation also because in 8.15 we included two important X.Org and OpenSSL patches for CVE-2024-9632 and CVE-2024-9143 respectively.

[Britgirl]

Your test proves that the culprit is not NoMachine, so disabling “nxserver for the time being” is not necessary. I’m not quite sure why you want to use NoMachine and the xterm for x-forwarding at the same time but with our Terminal Server products, you could run a custom session to access your python app rather than a desktop session. In any case, this is not the fault of NoMachine, but Gnome. If you try with XFCE for example, you won’t have this problem.

[Britgirl]

This is what we have planned to release in version 9, as part of the improvements we are implementing in profiles management in general.

[Britgirl]

Thanks for submitting the logs. We have checked them, and also reproduced. We are investigating further to see if it’s caused by a possible HW encoder limitation.

[Britgirl]

Ssh-ing in with your same tool with NoMachine installed and running is without issues for us. The problem can occur with Gnome apps when you are already logged in to the desktop locally with or without NoMachine because other x11 apps are fine i.e we can reproduce it even without NoMachine. It seems to be caused by the Gnome apps use of dbus and local session. If you are not logged in to the local Gnome desktop already, you cannot reproduce it. Restarting the Display Manager as you tried will also mean you are no longer logged in since you are rebooting to the login window on the desktop, that is why for you that workaround works.

Try this instead:

sudo systemctl restart display-manager  (so that you are no longer logged in to the local desktop)

sudo /etc/NX/nxserver --restart

and then SSH in. Are you able to reproduce the problem?

You could also try this if you have access to both machines at the same time: login physically to the desktop (sitting next to the RedHat machine without NoMachine). Then from your Windows device try and connect. What happens?

The alternative is to use a different desktop environment.

[Britgirl]

NoMachine installs without having to manually set permissions on all operating systems it supports. This includes macOS. It’s possible that you need to adjust macOS permissions because they were disabled by some security program on the Mac, so you should check if that’s the case on your machine. It’s also possible that you didn’t agree to something by accident during installation or that you disabled the permissions by mistake.

In any case, thanks for your suggestion. We have an illustrated guide for macOS users here who find themselves having to re-enable permissions.

https://kb.nomachine.com/AR11Q01061

[Britgirl]

Hi, thanks for reporting this, it’s an interesting use case 🙂 and we are investigating further. We’ll come back to you.

[Britgirl]

Can you tell us which “python-based programs” you are using, we are going to investigate further.

[Author]

Posts