Problem Description:
I needed Gwenview.
Tried to run it:
$ gwenview
Command ‘gwenview’ not found, but can be installed with:
sudo snap install gwenview # version 25.04.0, or
sudo apt install gwenview # version 4:23.08.4-0ubuntu1
See ‘snap info gwenview’ for additional versions.
$
So I tried
# snap install gwenview
error: cannot perform the following tasks:
- Run configure hook of “gwenview” snap if present (run hook “configure”: cannot perform operation: mount --rbind /home /tmp/snap.rootfs_pG6QWh//home: Permission denied)
- Run install hook of “mesa-2404” snap if present (run hook “install”: cannot perform operation: mount --rbind /home /tmp/snap.rootfs_16HqW3//home: Permission denied)
#
What am I doing wrong?
Any idea?
Relevant System Information:
Normal Xeon workstation, 256GB RAM, various SSD+HDD
Yes, it is Ubuntu Server LTS 24.04.2.
GUI was fairly easy to install using apt install xorg fvwm3 and some other stuff.
apt frequently used snap to install stuff (eg Firefox, LibreOffice etc).
So this time I decided to directly invoke snap, but that seems not to work for some reason I do not yet understand
Try switching from symlink to a bind mount, apparmor blocks on symlinks since it can not verify the integrity of the target … you should also see a matching DENIED entry in your journal for the above errors …
Yes, you are right, apparmor is the culprit.
Stopping and disabling it had no effect, snap didn’t succeed either, so I had to install the deb packaged version instead of the snap version, as I was in a hurry to select a few images.
Ideally if it would be possible to just get rid of apparmor this would be my preferred solution.
Err, no, apparmor is an essential security feature and deeply integrated with all layers of the Ubuntu OS nowadays (including most userspace apps)
You should just make your setup work properly with it by simply switching your home dirs from a symlink to a bind mount by either adding a single line to fstab or a system mount unit …
While snaps make the most use of apparmor, which is why it shows there most, pretty much all other apps do too to a certain extend nowadays.
Right now I have no time to learn AppArmor administration.
Thus I guess I have then to follow the advice on askubuntu to add to /etc/default/grub “apparmor=0” to the linux command line…
There’s nothing to learn about (unless you eagerly want to) it is already handled by the package maintainers, nearly every package that needs one in Ubuntu ships its apparmor profile already, with recent releases apparmor got way deeper integrated with the overall OS for security hardening, you will not need to do anything by hand usually…
Also note that snaps will likely stop working since apparmor is expected on Ubuntu (so the built in measures in snapd to operate without apparmor supported and enabled in the kernel will not kick in and snaps (i.e. Firefox) will simply break or mis-function)
Reading a bit around, I learned that apparmor was made obligatory not before 24.04.01
Thus apparently not too long ago
My feeling told me: Enter this:
systemctl stop apparmor
systemctl disable apparmor
Then edit into grub command line apparmor=0, update-grub and update-initramfs
reboot
apt purge apparmor
Here apt tells of some apparmor configuration directories not deleted
delete these manually
reboot again
system is clean and works fine
As @ogra said, as some part of snap gets snipped off, the old firefox, libreoffice profiles are lost… just what normally is stored in ~/.config, but in ~/snap on snap systems. Not a big deal, like a new installation.
Apparmor seems to be installed together with snap after you purged it and then install something snap-based.
# apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.
Maybe the purge was what stopped the annoying apparmor behavior, deleting all the annoying restricting rules.
Thank you guys! Luckily things turned out fine.
I can live with the “security issues” involved until I get time to learn more about AppArmor and figure out how to deal with that issue in a better way.
There is one clean and supported way to deal with it, by adding a single line to your fstab to use a bind mount instead of a symlink to provide your /home dir to the system.
It is really beyond me why you prefer to cripple your system like this (and move it that far away from any defaults which will most likely cause more problems in the future) just to keep the symlink around… but indeed, it is your system and your choice, happy I could at least provide some info…
I am still just evaluating Ubuntu, and right now I have other priorities than to please apparmor.
Apparmor in principle is no bad thing. It is default on since Debian Buster, and did not cause problems before with that kind of home directory symlinking to ZFS pools that I have been used to do on Debian since Buster.
So I think it might be worth to look at the apparmor configurations and compare them. There is definitely something wrong, either on Debians’ variant, or on Ubuntu’s one.
Why does apparmor cause such problems on Ubuntu, but not on Debian?
IMHO, this deserves investigation.
But as said, this is an evaluation system, I need to get accustomed with modern Linux and Ubuntu in particular. I am protocoling all important configurations, to have this scripted for the next installation etc. The base systems change, the home pool stays. So no need to worry about “crippling” my system
Apparmor doesn’t, it can, by design, not verify the integrity of symlinks since it lives on a very low level of the kernel to mediate file access (remember, everything in Linux is a file, even your devices) …
Symlinks are an implementation on a way higher layer, they are a filesystem specific implementation and usually live in the specific filesystem driver (not every filesystem supports symlinks)…
The level where apparmor operates is things the kernel itself understands (file open, read, close, move, mount etc) without a filesystem involved…
Your issue was around snaps, apparmor will not get in your way for other things that do not apply such strict security rules as snaps do (and that do not additionally run in namespaces and cgroups) by design snaps need to write to their specific snap dirs in your home, this is heavily mediated by apparmor, which is why you can not use a symlinks for /home dirs, it is that simple and it is super trivial to fix with a single line without messing up your whole system…
