Most snaps use strict confinement to isolate both their execution environments and their data from your system (see Snap Confinement for further details).
This confinement is an important security feature, but it can affect how and where you access a snap’s files, including:
- configuration files
- user documents
- internal databases
But it can also be helpful to understand how snaps operate on and access data, even without an interface, and this is outlined below:
- The snapd services downloads the snap as a single file – a compressed SquashFS archive with a .snap suffix.
- The snap file is uncompressed and mounted as a read-only filesystem under /snap. See The snap format for further details on what is included in a snap.
By design, the read-only filesystem is cannot provide a persistent experience between application launches, which is why snaps also have writable parts for system data and for user data.
Within the snap environment, environment variables are used to reference different accessible locations. The following variables and default referenced locations are used to store system data:
This directory is owned and writable by root and is used to store data that is common across multiple revisions of the snap (e.g.: revision 6, revision 7, etc.).
/var/snap/<snap name>/<revision number>
This location it is also used to store data, mostly information utilised by background application and services, for logging, and other tasks that require persistence between snap launches.
A snapshot of
SNAP_DATA is created and restored when performing a snap update (refresh) or revert operation. In contrast, a snapshot is not made of SNAP_COMMON.
Snaps can also contain user data. As with the system data environment variables,
SNAP_DATA, the following user-specific environment variables point to directories for user data:
This location maps user data across each revision of a snap. It is not backed up or restored on snap operations.
This contains any user data that the snap writes to its own home. This is in contrast to what the Linux user would consider their home. It is important to note this distinction, because it can be useful, and even important when users decide to perform maintenance operations with their snaps (like removal). By default, every snap will use a symlink current, pointing to the latest available revision.
Snaps without the home interface declared and/or connected cannot access the disk. The
$SNAP_USER_DATAdirectory will still be created and exist in the user’s home directory but it can contain no files
SNAP_USER_DATA only become available after a snap has been run once.
There are several other directories you should be aware of:
This is the working cache and is used to minimise download size and speed-up refreshes.
Contains all the versions of snaps installed on your system.
Contains both the manually generated and automatically generated snapshots.
Deleting a snap
When deleting and removing a snap from a system, the following will happen:
- The snap will be unmounted and no longer shown under
- The data under
/home/<username>/snap/will be deleted. However, a copy is be retained as a snapshot for 30-days (except on Ubuntu Core systems), allowing data to be restored or manually retrieved.
Snapshot management can be used to restore data, or unzip the archives, and only copy the data you consider necessary. With the right permissions, you can also create your own backup routine, which copies the important data like application databases, configurations or similar content to a backup path.
To remove a snap without generating a snapshot, use the additional ‘–purge’ argument:
$ sudo snap remove vlc --purge vlc removed