DevKnight

[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