On Ubuntu, some software installs as a snap instead of coming from the distribution archive. What is a snap, and what changes for you as an administrator when a program arrives as one?

## What a snap physically is A snap is a single **squashfs** file: a compressed, read-only filesystem image containing the application plus most of the libraries it depends on. Installing one does not unpack files across `/usr`; `snapd` places the image on disk and **loop-mounts it read-only** under `/snap/<name>/<revision>`, with a `current` symlink pointing at the active revision. Commands land in `/snap/bin`, which is on the default PATH on Ubuntu. This explains the first thing everyone notices: ``` $ df -h | head -3 Filesystem Size Used Avail Use% Mounted on /dev/loop1 74M 74M 0 100% /snap/core22/1122 /dev/loop2 165M 165M 0 100% /snap/firefox/4173 ``` Every mounted snap revision reports 100% use. That is not a problem to fix: a read-only image has no free space by definition, because it is sized exactly to its contents. Monitoring that alerts on "filesystem full" without excluding loop mounts will page you forever. ## Why the model exists A distribution archive gives you one version of a library shared by everything, patched centrally, curated per release. That is excellent for a coherent operating system and awkward for an application that wants to ship its own release cadence to five Ubuntu versions at once. A snap bundles its dependencies, so the publisher controls what runs and the same artifact works across releases. The cost is the mirror image of the benefit: bundled libraries mean the *publisher*, not Canonical's security team, is responsible for patching what is inside the snap, and disk and memory are duplicated across snaps that could have shared a library. Shared runtime snaps such as `core22` reduce that duplication somewhat — they are base snaps other snaps run against — but the model is fundamentally self-contained. ## Confinement is the part that surprises people A **strictly confined** snap runs under an AppArmor profile and a seccomp filter and starts with almost no access to the host. Everything it can reach beyond itself is expressed as an **interface** — `home`, `network`, `removable-media` and so on — and interfaces are either auto-connected by policy or connected manually: ``` $ snap connections firefox Interface Plug Slot Notes home firefox:home :home - removable-media firefox:removable-media - - ``` A slot shown as `-` means not connected, and that is the root cause of a whole family of bug reports: a snap application cannot open a file under `/mnt`, cannot read a dotfile directory, cannot see a path outside `$HOME`. Nothing is broken; the confinement is doing its job. `sudo snap connect <snap>:<interface>` is the fix when the access is legitimate. Some software cannot work under strict confinement — IDEs and toolchains that must see the whole filesystem — and is published as **classic** confinement, installed with `--classic`, which drops the sandbox and behaves much more like a normal package. Classic snaps require explicit review before publication precisely because they give up the isolation. ## Revisions, channels and rollback Snaps are not versioned by the archive. Each build in the store is a **revision**, and you subscribe to a **channel** written as `track/risk`, for example `latest/stable`, `latest/candidate`, `latest/beta`, `latest/edge`. Some publishers define additional tracks so you can stay on a major line rather than following the newest one. `snap info <name>` lists what a snap offers. Because old revisions are retained (snapd keeps a small number, controlled by `refresh.retain`), rolling back is a first-class operation: `sudo snap revert <name>` returns to the previous revision, and `--revision=` selects a specific one. That is genuinely better than what you get from a distribution package. The flip side is that snapd **refreshes automatically** on its own schedule, which is a different operational model from an archive you control — significant enough that it is worth treating as its own topic. ## Where you actually meet snaps on Ubuntu On **Ubuntu Desktop**, Canonical has moved some software to snap-only delivery: since 22.04 the `firefox` package in the archive is a transitional stub that installs the Firefox snap, and Chromium has been delivered the same way since 19.10. The practical consequences are real and worth naming in an interview: slower first start after a refresh, profile and download paths living under `~/snap/`, and automation such as browser-driver test harnesses breaking because the confined browser cannot reach the paths the driver expects. On **Ubuntu Server**, `snapd` is installed by default and several Canonical-adjacent tools are shipped primarily as snaps. Teams that want a strictly archive-managed server often remove snapd for exactly that reason. ## How to talk about it The balanced answer names what the model buys — self-contained delivery across releases, sandboxing, atomic revisions with real rollback — and what it costs: duplicated dependencies, patching responsibility moved to publishers, an update lifecycle you do not fully own, and confinement failures that look like application bugs. Blanket "snaps are bad" is a weak answer; so is pretending confinement never gets in the way.