Cannot open virtual desktops on free edition anymore

[LASR]

Hi!

I have a server running Debian 11 (freshly upgraded from Debian 10) that had previously ran GNOME over NoMachine free edition 8.4.2 with no issues. But after the upgrade and reinstallation of NoMachine 8.16.1, I am unable to open anything other than the physical desktop. I tried:

• Purging and reinstalling NoMachine 8.16.1
• Removing physical-desktop from AvailableSessionTypes in both /usr/NX/etc/node.cfg and /usr/NX/etc/server.cfg
• Updating my client and purging settings for this server (I’m running Ubuntu 24.04 with KDE)
• Reading the logs in debug mode
• Stopping and disabling gdm as suggested in https://kb.nomachine.com/AR03P00973

I have come to the conclusion that I’m in over my head and need guidance. I suspect this is related to https://forum.nomachine.com/topic/access-virtual-desktop-with-free-edition but the thread seems to be stale.

 

Here are the lines I edited to remove physical-desktop as an option:

$ grep ^AvailableSessionTypes /usr/NX/etc/node.cfg /usr/NX/etc/server.cfg /usr/NX/etc/node.cfg:AvailableSessionTypes unix-remote,unix-console,unix-default,unix-application,shadow,unix-xsession-default,unix-gnome,unix-xdm /usr/NX/etc/server.cfg:AvailableSessionTypes unix-remote,unix-console,unix-default,unix-application,shadow,unix-xsession-default,unix-gnome,unix-xdm

Please find attached:

• the server log
• my client’s logs

I will appreciate any help I can get, and I hope I didn’t miss any information. I will make sure to fix it ASAP if it is the case.

 

Cheers

Attachments:

1. nxserver.zip
2. R-localhost-41718-18F47208F377816FA4FF4AE1B5E36EC4-1.zip

[Britgirl]

Hi,

nothing has changed between NoMachine 8.4 and 8.16 in how NoMachine Free Edition works. If the server is not headless, you will connect directly to the physical desktop. On Linux, when connecting to the physical desktop which doesn’t have an X server running (e.g. it’s headless), NoMachine Free Edition is able to use its own display service (which is an embedded X server) to let a user connect seamlessly to a physical display running in the background on the remote machine. If you install it on a headless host, the following message appears:

“Cannot detect any display running, Do you want NoMachine to create a new display and proceed to connect to the desktop?”

Selecting OK will create a virtual display (NoMachine’s embedded X server). Is your Debian headless? Are you not seeing this message?

It’s worth pointing out that the free edition does not create virtual desktops like the terminal server products in the Enterprise suite. Virtual desktops are individual desktops, independent from each other that can run on the same server simultaneously and can be left running while you are disconnected. To be able to get multiple virtual desktops, you need a Workstation installed (or higher end product).

[LASR]

Hi and thank you for your reply!

That server is a VM on a cloud host provider but their manager interface can connect to it via VNC, which I suppose requires a physical display so it may be not technically headless.

ps aux|grep -v grep|grep "/usr/lib/Xorg"

returns nothing so I reckon I don’t have an X server running?

Which brings more questions then, especially given the wildly different behavior I’m experiencing:

I used to be able to open the session directly, and now I’m faced with the GDM login screen, which is redundant
I used to be able to resize the display to the size of the window, but now the display resolution is fixed and can only be stretched, selecting the 1:1 display option just shoves the display in the upper left corner or snaps the window back to its original size when resized

Is there a way to get the previous behavior back?

Thanks a lot!

[Britgirl]

If you have a vnc session running, killing it will then allow NoMachine to create the virtual xframebuffer session. After that restart the nxserver with nxserver --restart. Check what is configured in the DefaultDesktopCommand key in the node.cfg file. You could try using, for example, the same command you use on the vnc server.

If none of the above help, then we require the NoMachine logs with debug enabled from the server host. You should follow the instructions here https://kb.nomachine.com/DT07S00243, reproduce the problem, and then submit here or send to forum[at]nomachine[dot]com.

[LASR]

Ah, I think there was a misunderstanding, no VNC server is running on the VM! I do not have control over it, it is managed by our cloud service provider.

Should I provide the logs with or without physical desktop enabled?

[LASR]

So I’m not sure what exactly happened, but at some point I stopped and disabled GDM and re-added physical-desktop in the  AvailableSessionTypes lists, and now:

• NoMachine properly opens a session
• The screen resolution is properly adapted to the window size automatically

I’m not 100% sure what fixed it, I reckon it’s linked to GDM not running? I’m not sure to understand how exactly !M works. But problem solved I suppose?

[Britgirl]

Hi, I was just about to reply to you asking you to send the logs, but then you seem to have resolved the issue.

What I was going to mention was to not edit the AvailableSessionTypes key, since it should not be necessary – if you remove physical-deskop from the key, this will prevent you from connecting. So restoring the original cfg cofiguration was a good idea.

You mention GDM, so now we know you are connecting to a Gnome desktop. It would have been useful to know which command is used in the NoMachine node.cfg file. You can run the following to find out: grep DefaultDesktopCommand /usr/NX/etc/node.cfg.

But next time it happens and you can reproduce it, we need to see the logs with debug enabled from the Debian host you are connecting to. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243

I’m not sure to understand how exactly !M works

As I mentioned earlier NoMachine Free Edition lets you connect to the physical display, installs out-of-the-box and should not require configuration of node/server cfg files. On Linux when it can’t find an xserver running e.g the video card is turned off, NoMachine creates its own to let you access the desktop all the same. (see more about this here: https://kb.nomachine.com/AR10K00700). About the resolution, take a look at the following article: https://kb.nomachine.com/AR02M00836. I’m not sure what changed suddenly that now means you connect correctly and see the display at the proper resolution, but it’s most likely due to the desktop configuration or system. As I said if it happens again, logs and also screenshots would be useful.

[LASR]

Hi,

Thank you for the clarification, I didn’t know the free version was only limited to physical-desktop.

I did mention we use GNOME in my first message. Here’s the command defined in node.cfg:

DefaultDesktopCommand "/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager"

I also did provide logs in debug mode in my first message, maybe a screenshot would have helped.

 

Thank you for the explanation. As it happens, this is exactly what is happening right now:

sudo /etc/NX/nxserver --restart
NX> 162 Disabled service: nxd.
NX> 162 Disabled service: nxserver.
NX> 162 Service: nxnode already disabled.
NX> 111 New connections to NoMachine server are enabled.
NX> 161 Enabled service: nxserver.
NX> 162 WARNING: Cannot find X servers running on this machine.
NX> 162 WARNING: A new virtual display will be created on demand.
NX> 161 Enabled service: nxd.

Unfortunately, our use case still requires editing config files, if only to prevent NoMachine from messing with firewall rules without asking and to automatically close sessions. Which every software update seems to overwrite back to defaults, for some reason, but that probably deserves its own thread.

[Britgirl]

I did mention we use GNOME in my first message.

Yes, you are right!

About the firewall, when installing NoMachine, it creates rules for the nomachine service, without these nomachine would be blocked.

Which every software update seems to overwrite back to defaults,

I’m not sure what you mean. When installing an update, your previous configuration should be maintained. If something is being overwritten, it definitely deserves a new topic as you wrote 🙂

[DevKnight]

Hey Britgirl and LASR,

Awesome thread, and thanks for the insights! Stumbled upon this wrestling with a very similar GNOME virtual desktop beast on a headless Arch Linux setup on Google Cloud VM instance with the latest NoMachine. Took a lot of trial and error (and some late-night AI brainstorming sessions, lol) but finally got a stable, fully working GNOME session.

For me, the absolute key was getting the DefaultDesktopCommand in /usr/NX/etc/node.cfg just right. LASR, since you mentioned your Debian setup used to work and now you’re seeing GDM or different behavior, maybe this approach could help get you back to that more direct session startup.

This is the DefaultDesktopCommand that finally did the trick for me on Arch:


DefaultDesktopCommand "env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY XDG_SESSION_TYPE=x11 XDG_SESSION_DESKTOP=GNOME XDG_CURRENT_DESKTOP=GNOME GNOME_SHELL_SESSION_MODE=gnome DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus /usr/bin/gnome-session --session=gnome"

The core ideas behind why this worked for me were:

Explicitly setting

DBUS_SESSION_BUS_ADDRESS:

Making sure it points directly to the systemd user D-Bus socket (unix:path=/run/user/$(id -u)/bus). This was crucial.

NOT using dbus-run-session OR dbus-launch --exit-with-session in the command itself: While those tools are often used to ensure a D-Bus session, in my case they seemed to prevent gnome-session from properly seeing its XDG_SESSION_ID which is vital for full logind and systemd –user integration. Once I removed dbus-run-session and just set the address, GNOME (specifically gnome-shell) was smart enough to find its logind session itself.

Standard gnome-session command: Just letting /usr/bin/gnome-session --session=gnome run after the environment was set.

@LASR, your paths might be slightly different on Debian (e.g., how gnome-session is typically called if not via x-session-manager), but the principle of ensuring DBUS_SESSION_BUS_ADDRESS points to your user’s systemd D-Bus socket (usually under /run/user/YOUR_UID/bus) and then launching gnome-session might be worth a shot. It sounds like your previous DefaultDesktopCommand (/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager) was already close but perhaps the dbus-launch part was causing similar issues to what dbus-run-session did for me.

And like you discovered, ensuring GDM isn’t trying to “own” the display NoMachine is using seems to be a common theme.

Hope this gives another angle to try! It’s definitely tricky when the free edition is focused on that “physical display” paradigm on headless systems.

Cheers!

[Author]

Posts