On an Ubuntu server, `df -h` lists a dozen /dev/loopN filesystems mounted under /snap, every one of them reporting 100% used. What are those mounts, is the 100% a problem, and how do you get a readable df and find where snap disk usage really is?

## What the loop mounts are A snap is distributed as a single squashfs image — a compressed, read-only filesystem in one file. On install, snapd writes that file to `/var/lib/snapd/snaps/<name>_<revision>.snap`, attaches it to a free loop device, and mounts it at `/snap/<name>/<revision>`. A per-snap `current` symlink points at the revision in use. Because snapd keeps more than one revision of each snap, and because base snaps (`core22`, `core24`), the `snapd` snap itself and the desktop runtimes are all snaps too, even a modest server accumulates a double-digit number of these mounts. The mounts are not ad-hoc: snapd generates systemd mount units for them, named after the mount point with dashes for slashes. You can list them: ```bash systemctl list-units --type=mount | grep snap findmnt -t squashfs ``` ## Why every one reads 100% A squashfs image is built to hold exactly the files it contains and is mounted read-only. There is no free space by construction and there never will be, so `df` computes used/size as 1.00 and prints `100%`. This is the single most reported non-problem in snap operations. The correct response is to stop reading it as a capacity signal — and, on the monitoring side, to exclude squashfs (and usually loop devices generally) from disk-full alerting, because otherwise every Ubuntu host permanently reports full filesystems and the alert becomes noise that trains people to ignore real ones. ## Getting a readable df ```bash df -h -x squashfs ``` `-x <type>` excludes a filesystem type; `-t <type>` is its inverse and shows only that type, which is occasionally useful for auditing. Neither changes anything on disk. `findmnt` and `lsblk` give the same picture in a friendlier shape, and `lsblk` will show the loop devices with their backing files under `/var/lib/snapd/snaps/`. ## Where the space actually goes The loop mounts consume no space of their own; they are views onto files that already exist. Real consumption is in three places: - `/var/lib/snapd/snaps/` — the `.snap` image files, one per retained revision per snap. This is the big one. - `/var/snap/<name>/` — per-revision and common writable system data for each snap. - `~/snap/<name>/` — per-user data, which lives in home directories and therefore lands wherever home is. So the honest measurement is: ```bash sudo du -sh /var/lib/snapd/snaps /var/snap snap list --all ``` `snap list --all` shows every revision snapd is holding, including ones marked `disabled` in the Notes column — those are the retained older revisions kept so a rollback is possible. ## Retention By default snapd retains three revisions of each snap on a classic system (two on Ubuntu Core), pruning the oldest as part of a refresh. The setting is a system-level snap option: ```bash snap get system refresh.retain sudo snap set system refresh.retain=2 ``` The accepted range is 2 to 20. Note the trade: lowering it reclaims disk but shortens how far back you can revert, and two is the floor precisely because keeping one previous revision is what makes rollback possible at all. Setting it does not delete anything immediately — pruning happens on the next refresh of each snap. To reclaim now, remove a specific disabled revision with `snap remove --revision=<N> <name>`, and remove a snap you no longer want entirely with `snap remove --purge <name>` (the `--purge` also discards its data snapshot). ## When it is genuinely a problem Two real failure modes hide behind the noise. First, `/var` filling up: on hosts where `/var` is a small separate filesystem, retained snap revisions plus base snaps can be gigabytes, and that shows in `df` on `/var`, not on the loop mounts. Second, loop device exhaustion is possible in principle on constrained systems, and a snap whose mount unit failed to start leaves `/snap/<name>/current` dangling so the command simply does not run — `systemctl status snap-<name>-<rev>.mount` and `journalctl -u` on that unit tell you which. The interviewing point is discrimination: a page that fires because a read-only image is exactly full is a monitoring defect, while a page for `/var` at 95% on a snap-heavy host is a real one, and they look similar in a `df` you have not filtered.