My hosting provider upgraded my VM recently, giving me a virgin CentOS. The emacs I had added to the VM years ago was gone, and I forgot what system I used to install it, so I did a web search, found this article, and installed the described snap. The installation went fine and emacs worked fine. To me, the entire process was a black box.
Several weeks later, I started getting messages from cPanel/WHM that :
The filesystem “/var/lib/snapd/snap/emacs/966” mounted at “/var/lib/snapd/snap/emacs/966” reached “critical” status because you currently use 100% of its available inodes.
I posted some information on this topic in the cPanel forum to get help, but the consensus is that the snap performed some gratuitous manipulation of mountpoints that they can’t explain. See the link for technical details and the discussion so far.
The question is, do I need to do something about this message, and if so, what?
Snaps are distributed as compressed squashfs filesystems, rather than being extracted, they are mounted at runtime, this applies to all snaps and not just the Emacs snap.
This is similar to the approach AppImage takes, and certain application installers on MacOS. It provides benefits in simplifying upgrades and ensuring the package isn’t modifiable by being able to trivially check its signature, and to some people some disadvantages in that it appears in ‘lsblk’ output and similar, and similarly this is why your software is concerned that it sees a filesystem that is 100 percent full.
But it’s supposed to be 100 percent full anyway, because being less than fully at capacity would just be wasted space, the automatic updates will replace the mountpoint rather than add to it, so theres nothing to worry about.
Tl:;Dr it’s working as designed, you can ignore the error in this case and if you can exclude a directory from being checked, safely silence it by excluding /var/lib/snapd/snap
