My guess is that some part of the systemd session start logic is not invoked by nomachine or x2go. There is some difference in code paths which leads to an unexpected value for DBUS_SESSION_BUS_ADDRESS. Nomachine does the login itself, and then starts the graphical session. When using these remote access apps to access a virtual desktop sessions, there is no login managed by a traditional display manager. I don't know why DBUS_SESSION_BUS_ADDRESS is wrong when nomachine or x2go starts the session. 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. 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. I don't use x2go but users report identical problems, so I guess it is also sharing a virtual desktop. Nomachine virtual desktops are associated with the nomachine workstation server or other terminal-server style products, not with the basic nomachine desktop sharing client. This applies only to confined snaps, which is most of them. Snap apps in Ubuntu when started in nomachine virtual desktops or x2go give an error, and they don't run.
0 kommentar(er)
