<div dir="ltr"><div>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.</div><div>In fact, the users having this problem mostly have in common that their session is started with a remote desktop session. <br></div><div>such as </div><div>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. <br></div><div><br></div><div>Comment 17 implies that the problem is the user session is not being setup correctly. <br></div><div><div><a href="https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17" target="_blank">https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17</a></div></div><div><br></div><div><br></div><div>An expert commentor <span role="gridcell"><span name="Maciej Borzecki"><span>Maciej Borzecki said: </span></span> </span></div><div style="margin-left:40px">I've commented before, but if your desktop session is correctly set up,<br>
the systemd --user instance should be available, then a transient scope<br>
can be created for snap and proper device access filtering can be set up<br>
in that cgroup, thus completing the sandbox. Cgroup v1 works<br>
differently, in that there is a separate hierarchy which could be set up<br>
for a snap and there's no need to ask ssytemd to set up anything on<br>
behalf of the snap. This is no longer the case for v2.<br>
<br>
AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble<br>
seems to be coming from X2go/vnc or similar solutions which appear to<br>
give you a desktop access, but it's half baked, and are either missing<br>
session dbus or the systemd --user instance. Perhaps it's not really<br>
going through PAM, hence things that would have been set up through<br>
pam_systemd are missing.</div><div><br></div><div><div>Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not correct. <br></div><div><br></div><div>A typical fix is for users to do this:</div><div><br></div><div>export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"</div><div><br></div><div><br></div><div>before running the snap.</div><div>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.</div></div><div><br></div><div>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. <br></div><div><br></div><div>I think the problem is in the login stage, as Maciej says.<br></div><div>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.</div><div>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.<br></div><div><br></div><div>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. <br></div><div><br></div><div>x2go
 is barely maintained, which is a hint to me that the login process 
needs some kind of systemd enhancement missing in older code.<br></div><div><br></div><div>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</div><div><br></div><div>How could I prove to nomachine tech support that nomache workstation iis not logging in correctly?<br></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Tim Richardson<br></div></div>