I cannot run Chromium on an Ubuntu Server with a particular user. Actually, this can be reproduced with a fresh Ubuntu Server 22. The following commands are run by philippe, the user created during Ubuntu setup:
# Install Chromium
$ sudo snap install chromium
(...)
# Launch Chromium (okay, just print its version)
$ chromium --version
Chromium 108.0.5359.124 snap
# Create another user
$ sudo adduser otherphil
(...)
# Log as the new user
$ sudo su otherphil
# I expect Chromium to be available for this new user but...
$ chromium --version
/user.slice/user-1000.slice/session-3.scope is not a snap cgroup
Note:
In the last error message, 1000 is the id of philippe, the first user who installed Chromium and who can run it. Not the id of otherphil, the new user who can’t run Chromium.
otherphil still can’t run Chromium when he is made sudo and installs the snap himself.
I would expect Chromium to work for any user. What am I doing wrong?
I’m not sure about the specifics, but this has something to do with the way the sessions are made. I’m mildly surprised that neither sudo -iu otherphil nor sudo login followed by logging in as otherphil works, but my own reproduction of this issue on Ubuntu 22.04 went as follows:
Using sudo -i or sudo -s: error
Using sudo su or sudo su -: error
Using sudo login: error
But…
sshing to localhost as the other user: Success
Switching to another virtual terminal and logging in as the other user: Success
Setting SNAPD_DEBUG=1, I see that an SSH session puts the process into the correct cgroup, whereas sudo -i doesn’t.
When I use ssh, then loginctl list-sessions shows two sessions (one for myself and one for my test user). However, sudo and su (even sudo login) don’t create a session.
You can get a similar control group issue by suing into that user and running systemd --user:
$ systemd --user
Failed to create /user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied
So it appears that even after suing we’re still in the same user-1000 systemd slice. (Running sleep 100 from that other user’s terminal and then loginctl user-status confirms this, as I can see that sleep process under my own user). Likewise, SSHing in creates a new user-1001 slice. (You can SSH in and then try loginctl user-status otherphil to see that slice).
I’m not familiar enough with how systemd handles sessions, seats, etc. to figure it out, but hopefully the ssh workaround is sufficient for you!
