fra81

[fra81]

Hi, can you try to run sudo /etc/NX/nxserver --eglcapture yes and then reboot, just to make sure the EGL library is properly loaded? If you still reproduce the problem after these steps, please send in new logs.

[fra81]

Hi,

please try Option #2 of the article (run sudo /etc/NX/nxserver --eglcapture yes and set WaylandModes "egl,compositor,drm") and reboot to make sure the EGL library is loaded into the system. If you still reproduce the problem after that, send new server logs.

[fra81]

We see this in the logs:

(process:6599): dconf-CRITICAL **: 14:50:08.603: unable to create file ‘/home/rbuehlma/.cache/dconf/user’: Permission denied. dconf will not work properly

You could try to adjust the permissions for the ‘/home/rbuehlma/.cache/dconf’ dir until that error in the logs goes away. It is normally owned by the logged-in user with 700 permissions.

And did you enable the ‘Blank the physical screen when somebody connects’ option? If that is the case, please try to disable it and see if the problem persists.

[fra81]

Hello, we tried to reproduce this issue without success. It actually seems more like a system issue than a NoMachine issue.

Regarding the steps you mentioned before:

– Start the PC and work locally
– Lock screen when leaving
– Login from remote
– Disable second monitor in Gnome settings (since my remote station has only one screen)
– Terminate NoMachine session (Local screen gets locked)
– Login locally
– Re-enable second monitor -> Monitor gets active but stays black

Please try to change those steps by re-enabling the second monitor before terminating the NoMachine session, i.e.:

– Start the PC and work locally
– Lock screen when leaving
– Login from remote
– Disable second monitor in Gnome settings (since my remote station has only one screen)
– Re-enable second monitor
– Terminate NoMachine session (Local screen gets locked)
– Login locally

Is the monitor black when you will login locally?

[fra81]

Hi, from the logs, we see that a Windows API isn’t returning the expected monitor count, so strictly speaking, this isn’t a nomachine bug. However, we plan to make our monitor checks more reliable and less dependent on that single API. You can expect improvements in a future release.

[fra81]

That’s strange. There might be a different problem now. Just to be sure, would you please check the getcap command and the nx-sourceenv.sh script again after you experience one of these white screens? Also a new set of logs from the server – gathered while you are experiencing the white screen – could be useful, given that this could be a different issue. Thanks for your patience!

[fra81]

Hi @rbuehlma,

can you show the output of these commands (you can copy the output to a file) taken while the monitor is black?

gdbus call --session --dest org.gnome.Mutter.DisplayConfig --object-path /org/gnome/Mutter/DisplayConfig --method org.gnome.Mutter.DisplayConfig.GetCurrentState
gdbus call --session --dest org.gnome.Mutter.DisplayConfig --object-path /org/gnome/Mutter/DisplayConfig --method org.gnome.Mutter.DisplayConfig.GetResources

Does disabling and re-enabling the second monitor (without connecting remotely) help to make the monitor visible again?

[fra81]

Hi @yumpo,

could you follow the steps below, if you are available?

1. Show us the output of the sudo getcap /usr/bin/kwin_wayland command
2. Show us the content of the /etc/xdg/plasma-workspace/env/nx-sourceenv.sh file, if existing
3. Run sudo /usr/NX/bin/nxserver --eglcapture yes and comment out the WaylandModes key (to restore its default value)
4. Show us the output of the sudo getcap /usr/bin/kwin_wayland command again
5. Logout and login again to the Wayland desktop, and let us know if it still doesn’t work

[fra81]

Please reboot the system (or at least restart the desktop manager). This will make sure the updated libnxegl library is loaded into the system. If you still experience problems after that, please send the logs again. Thank you for your cooperation!

[fra81]

Can you clarify what is crashing exactly? A system process or the NoMachine server? Is there a crash report to share with us?

Please also gather the logs as explained in https://kb.nomachine.com/DT08U00298#1. Also the journalctl output can be useful. You can send all of that to forum[at]nomachine[dot]com.

[fra81]

@theblackhole,

it looks like you still have the WaylandModes key in /usr/NX/etc/node.cfg set to ‘drm,egl,compositor’. Please try to restore it to its default value (WaylandModes egl,drm,compositor) or comment it out altogether. In version 9.1.24 all known issues with the egl mode were fixed.

If that doesn’t solve the problem, please collect a new set of logs after having restored the key to the default value. Also tell us whether the server machine is headless or its monitor is turned off. In that case, does anything change if you connect a monitor or turn it on?

 

[fra81]

Hi,

that’s strange. Kubuntu 25.04 works well in all our tests with version 9.1.24. Is it possible that you didn’t reboot the server after updating NoMachine? This would be necessary to make sure the new libnxegl library is preloaded. Logging out should be enough but rebooting is the safest option.

If that doesn’t help, please gather server logs as explained in https://kb.nomachine.com/DT08U00298#1. You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi Joe,

we would need to see the backtrace from the core file. You can find all the instructions here: https://kb.nomachine.com/AR09L00810

Server side logs can also be useful: https://kb.nomachine.com/DT08U00298#1.1

You can send all of that to forum[at]nomachine[dot]com, by referencing this topic.

[fra81]

It’s probably because you have to edit it as a privileged user. Anyway, you can simply open a Terminal and paste this command there:

echo 'DisplayServerExtraOptions "-nosckgrab"' | sudo tee -a /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg

That will do the trick. Then you have to restart the NoMachine server with this command to apply the change:

sudo /etc/NX/nxserver --restart

[fra81]

Hi pupu,

since I suspect the root cause may be the same, please retrieve the same information that was asked by Bilbotine in this post: https://forum.nomachine.com/topic/black-screen-connecting-to-rocky-linux-9#post-54100. Do that after going to back to the original situation that was giving you the crash.

Thank you in advance for your help.

[Author]

Posts