snap apps in Ubuntu when started in nomachine virtual desktops or x2go give an error, and they don't run. This applies only to confined snaps, which is most of them.
nomachine virtual desktops are associated with the nomachine workstation server or other terminal-server style products, not with the basic nomachine desktop sharing client. I don't use x2go but users report identical problems, so I guess it is also sharing a virtual desktop.
The known work-arounds are to either alter snap sandboxing by disabling cgroups v2, or to manually simulate the normal value of DBUS_SESSION_BUS_ADDRESS. The first is simple but dramatic since cgroups v2 is a big part of the modern linux experience, and the second solution is a hack which can break under multiple users.
I don't know why DBUS_SESSION_BUS_ADDRESS is wrong when nomachine or x2go starts the session. When using these remote access apps to access a virtual desktop sessions, there is no login managed by a traditional display manager. Nomachine does the login itself, and then starts the graphical session. I assume x2go does the same thing. There is some difference in code paths which leads to an unexpected value for DBUS_SESSION_BUS_ADDRESS. My guess is that some part of the systemd session start logic is not invoked by nomachine or x2go. But it has been hard for me to understand. I realise I don't have a nuts and bolts idea about how linux login works, and I can't find documentation that I can understand.
(I think that a "screen sharing" session connecting to a physically present session, such as nomachine desktop, does not have this problem since it does not bypass the display manager)
My experience is with nomachine, but x2go users are reporting the same problem, and the same workaround works there too.
With a nomachine virtual desktop in either xubuntu or ubuntu,I can't start confined snaps such as firefox (unless cgroups v2 is disabled via a kernel parameter).
The error when started from a terminal looks like this:
tim@ubuntu ~/Desktop $ firefox /user.slice/user-1000.slice/session-c3.scope is not a snap cgroup
but one of the root causes of the problem seems to be that the
DBUS_SESSION_BUS_ADDRESS is set up incorrectly. It does have a value, but one which is very different to a normal, display-manager session.
In a typical Ubuntu login, we see something like this:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
but in the broken nomachine session, we see something like this:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
If I manually set DBUS_SESSION_BUS_ADDRESS, confined snaps work.
For example, if in nomachine I start xfce like this:
DefaultDesktopCommand "env
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4"
snaps work.
The problem only manifests for confined snaps when cgroups v2 is running. So confined snaps, hence sandbox, must be a factor too. For this reason, many are convinced it is a snap bug, but the snap devs, not so much.
Looking at the strange value for DBUS_SESSION_BUS_ADDRESS, I conclude that the session is not being set correctly. The way nomachine starts the session must be different to how the display managers work. DBUS_SESSION_BUS_ADDRESS is set in the systemd login process, before the graphical session starts.
The other possibility is that
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
is a perfectly valid value, but that snap's sandboxing doesn't like it (unconfined snap apps have no problem).
The workaround with the least hassle is to disable cgroups v2 and this is what nomachine advises.
Why is DBUS_SESSION_BUS different when nomachine or x2go do the login?
