This is the information about /dev/sdb5: Mounted on /, /var/snap/firefox/common/host-hunspell.
Does anyone understand what this mean, why firefox/common is mentioned here?
Thanks!
This is a consequence of the work to enable exposing a user’s spellchecking dictionaries to the firefox snap. The implementation creates a bind-mount of the host system’s /usr/share/hunspell in a place where the confined firefox can see it (/var/snap/firefox/common/host-hunspell).
This is working as intended, and can be safely ignored.
I removed the firefox snap and the mount was still there after rebooting. I removed the hunspell snap and still the mount persists. How do I remove this /var/snap/firefox/common/host-hunspell from my system (Ubuntu 22.04)??
EDIT: I see I have a service running: var-snap-firefox-common-host\x2dhunspell.mount
Should this be removed when I remove the snap? Or do I need to manually remove it, and if so how do I do that? Thanks!
â—Ź var-snap-firefox-common-host\x2dhunspell.mount - Mount unit for firefox, revision 1860 via mount-control Loaded: loaded (/etc/systemd/system/var-snap-firefox-common-host\x2dhunspell.mount; enabled; vendor preset: enabled) Active: active (mounted) since Wed 2022-09-28 11:43:09 PDT; 19min ago Where: /var/snap/firefox/common/host-hunspell What: /dev/nvme0n1p5 Tasks: 0 (limit: 18849) Memory: 4.0K CPU: 707us CGroup: /system.slice/var-snap-firefox-common-host\x2dhunspell.mount
Sep 28 11:43:09 SEi-Mini systemd[1]: Mounting Mount unit for firefox, revision 1860 via mount-control… Sep 28 11:43:09 SEi-Mini systemd[1]: Mounted Mount unit for firefox, revision 1860 via mount-control.
What exactly is your concern with that mount ?
Mounting single directories from one snap to the other under strong security constraints is exactly how safe content sharing between snaps works.
this is desired and expected behavior (and yes, indeed, if you remove both snaps the mount will be gone along with them, but i still fail to see why anyone would do that and am very curious what bothers you about it (do mounts of /proc, /sys or /tmp bother you too ?))
What exactly is your concern with that mount ?
The mount itself doesn’t concern me. What I am concerned about is that it shows up as a block device on my root partition.
Mounting single directories from one snap to the other under strong security constraints is exactly how safe content sharing between snaps works.
I am a long time Unix and Linux user (going back 35 years) but I am new to the concept of snaps. The solution chosen to provide isolation and security has the side effect of creating quite a lot of devices on my system that don’t actually exist. They’re virtual, apparently, though in my opinion it would be nice to separate out real, physical devices from useful fictions. Since I don’t use Firefox, the hunspell device taking ownership of my root device doesn’t provide any benefit to me.
this is desired and expected behavior (and yes, indeed, if you remove both snaps the mount will be gone along with them, but i still fail to see why anyone would do that and am very curious what bothers you about it (do mounts of /proc, /sys or /tmp bother you too ?))
I removed both snaps and the hunspell bind mount (in /etc/systemd/system) remained. The only way I found to eliminate it is to delete the .mount file manually. That seemed clumsy to me.
Note that proc, sys, tmp mounts do not show up as block devices. There is no “bind” associated with them (another new concept for me, whose purpose is not yet clear). Always new things to learn, so I try not to be too stuck in my ways.
they are actual physical filesystem images that happen to reside on top of your rootfs disk (in /var/lib/snapd/snaps) and get mounted into mount points under /snap … you should perhaps file a kernel bug so squashfs (as well as .iso and other .img format) file based mounts do not show up as belonging to the disk they sit on …
how exactly did you remove them ? a proper:
sudo snap remove <snapname>
should trigger systemd to remove all remaining units for services and mounts shipped by the respective snaps (along with a good bunch of other things that were auto-generated by systemd, apparmor_parser and other system utilities when you install them or connect an interface) …
if this did not happen when using the proper command, please file a bug with:
ubuntu-bug snapd
how exactly did you remove them ? a proper:
sudo snap remove <snapname>should trigger systemd to remove all remaining units for services and mounts shipped by the respective snaps (along with a good bunch of other things that were auto-generated by systemd, apparmor_parser and other system utilities when you install them or connect an interface) …
Yes, I used that command. If I recall correctly, I removed the hunspell snap first so perhaps that prevented the firefox snap from noticing the hunspell mount? If I have time later I’ll try to duplicate the issue before posting a bug report.
1 Like
The hunspell mount that you mention in association with firefox isn’t taking over your root partition at all. The reason that the device node of your root filesystem is associated with this particular mount is because the bind-mount is referencing a directory that is contained within the filesystem on that device node (specifically /usr/share/hunspell). This is what my own mount output shows for the hunspell mount:
/dev/sde on /var/snap/firefox/common/host-hunspell type ext4 (ro,noexec,noatime,discard,errors=remount-ro,data=ordered)
This mount is generated by the plug defined inside the firefox snap, which is automatically connected:
host-hunspell:
interface: mount-control
mount:
- what: /usr/share/hunspell
where: $SNAP_COMMON/host-hunspell
persistent: true
options:
- ro
- bind
- noatime
- noexec
You may disconnect, and therefore remove the mount entry, with the following command-line:
snap disconnect firefox:host-hunspell
This will be marked as a manual decision and will not be overridden once you’ve disconnected the plug.
Looks like it’s harmless,
Thanks to @ogra
1 Like
I agree with @kpa the mount points dedicated to snap should be listed differently because it creates some kind of confusion when dealing with / monitoring often and many « physical » mounts. Ok it’s not everyone’s everyday business, but a daily reality for some of us, poor admins.
Maybe it’s a lsblk thing, an option to exclude those mounts from listing ?
Those days it’s only concerning Firefox but what will happen later if each snap has its own bind-mounts for this or that ?
By the way you may do the same kind of bind-mounts for Gimp, for it to be able to write thumbnails for its .xcf files into ~/.cache/thumbnails ?
I’ve added an alias to my .bashrc:
alias lsbl='lsblk --exclude 7'
This allows me to lsblk while excluding the loop (squashfs) devices. However it does not exclude the bind mounts.
Thanks, I knew that one, am used to
lsblk -fe7,11 -o +size,models,ro
Problem here ( on ubuntu 22.04 at least ) is if /var/snap/firefox/common/host-hunspell exists, it will somehow hide the regular and expected / partition.
lsblk -fe7,11 -o +size,model,ro
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS SIZE MODEL RO
nvme0n1 476,9G SAMSUNG MZALQ512HBLU-00BL2 0
├─nvme0n1p1 vfat FAT32 SYSTEM_DRV 00D0-6037 220,4M 14% /boot/efi 260M 0
├─nvme0n1p2 16M 0
├─nvme0n1p3 ntfs Windows-SSD 8484D0F584D0EB26 266,7G 0
├─nvme0n1p4 ntfs WINRE_DRV E6F8D225F8D1F3B1 1000M 0
└─nvme0n1p5 ext4 1.0 7c03d2c5-dd09-4237-9a71-5f7ccaf51c69 169,2G 12% /var/snap/firefox/common/host-hunspell 209G 0
nvme0n1p5 is actually the / partition…
So I don’t know if this is a “feature” or a bug of
mounting single directories from one snap to the other under strong security constraints is exactly how safe content sharing between snaps works.
this is desired and expected behavior (and yes, indeed, if you remove both snaps the mount will be gone along with them, but i still fail to see why anyone would do that and am very curious what bothers you about it (do mounts of /proc, /sys or /tmp bother you too ?))
but it seems like it prevents launching Firefox on X over SSH: https://pastebin.com/4cvPrVQe
I don’t normally launch web browsers over SSH but I needed today and there’s far too much open in Chrome to launch that. I do, however, launch a lot of other thing over it and I’ve never seen this problem before.
As for why it bothers me? This was a good enough reason for me to just copy it. I also don’t like how much more size snaps/flatpacks take up. If it’s a choice between a snap and compiling, I select the latter because of the size issue.
I am a long time Unix and Linux user (going back 35 years) but I am new to the concept of snaps. The solution chosen to provide isolation and security has the side effect of creating quite a lot of devices on my system that don’t actually exist. They’re virtual, apparently, though in my opinion it would be nice to separate out real, physical devices from useful fictions. Since I don’t use Firefox, the hunspell device taking ownership of my root device doesn’t provide any benefit to me.