There is a long standing and long bug report in Ubuntu which attributes the inability to start the Firefox snap (or any snap with sandboxing) to snapd. In fact, the users having this problem mostly have in common that their session is started with a remote desktop session. such as nomachine (workstation, which starts a virtual session) and x2go, and sometimes various vnc connections, those which spawn remote sessions rather than screen sharing an existing session, I suspect.
Comment 17 implies that the problem is the user session is not being setup correctly. https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17 An expert commentor Maciej Borzecki said: I've commented before, but if your desktop session is correctly set up, the systemd --user instance should be available, then a transient scope can be created for snap and proper device access filtering can be set up in that cgroup, thus completing the sandbox. Cgroup v1 works differently, in that there is a separate hierarchy which could be set up for a snap and there's no need to ask ssytemd to set up anything on behalf of the snap. This is no longer the case for v2. AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble seems to be coming from X2go/vnc or similar solutions which appear to give you a desktop access, but it's half baked, and are either missing session dbus or the systemd --user instance. Perhaps it's not really going through PAM, hence things that would have been set up through pam_systemd are missing. Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not correct. A typical fix is for users to do this: export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" before running the snap. snaps are surfacing this problem for some reason but I don't think it is snap problem. When the snap launches it finds itself in an unexpected cgroup. In one of my experiments, running systemd --user in a shell and starting a snap from there worked. It was when I compared the environment generated here vs the environment after logging in via nomachine that I discovered the workaround of exporting that variable. But it is not a very good workaround. It only allows one session per user, for instance. I think the problem is in the login stage, as Maciej says. I can't find documentation on how the "modern" login process works, at least detailed enough to explain how you make sure the pam_systemd setup is invoked. I got lost in the scripts trying to work it out. I have no practical understanding of the login process, so I am bad person to be asking this question, but no one else seems to trying. Just a lot of complaining users adding to the bug report. I use nomachine, and while I have mentioned my suspicions to their tech support, I can't be very technically convincing since I don't understand what has changed in the login process causing them to miss something. x2go is barely maintained, which is a hint to me that the login process needs some kind of systemd enhancement missing in older code. Is there someone on this mailing list who can join the dots and give good clues about what might be going wrong with the login process of nomachine, x2go etc How could I prove to nomachine tech support that nomache workstation iis not logging in correctly? -- Tim Richardson
