Snaps are self-contained applications, isolated from the underlying operating systems by several layers of confinement. This mechanism introduces security benefits, but it may also create confusion for people who are less familiar with how snaps work and behave, especially when it comes to filesystem access. Today, we’d like to clarify some of the questions and misconceptions around how snaps manage system and user data.

Snap installation

When a user installs a snap from the Snap Store, the following happens:

• The snapd services downloads the snap – a compressed squashFS archive with a .snap suffix.
• The snap is uncompressed and mounted as a read-only filesystem under /snap.

A read-only filesystem is insufficient in providing a meaningful, persistent experience between application launches, which is why snaps also have writable parts:

• SNAP COMMON – Reflected in the SNAP_COMMON environment variable, this directory is owned and writable by root, and it used to store data that is common across multiple revisions of the snap (e.g.: revision 6, revision 7, etc.).
• SNAP DATA – Reflected in the SNAP_DATA environment variable, it is also used to store data, mostly information utilized by background application and services, for logging, and other tasks that require persistence between snap launches. This directory is backed up and then restored when performing a snap update (refresh) or revert operation. In contrast, SNAP_COMMON is not.

User data

Much like system data, snaps can contain user data. In a manner similar to the COMMON and DATA environment variables owned and writable by root, there are also user-specific directories available. However, the user-specific directories will not be created until the specific user has run a snap for the first time.

SNAP_USER_COMMON – This directory maps to user data that is common across revisions of a snap. A typical path would be something like: /home/”username”/snap/”snap name”/common. It is not backed up or restored on snap operations.

SNAP_USER_DATA – This directory will contain 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). A typical path would be: /home/”username”/snap/”snap name”/”revision”. By default, every snap will use a symlink current, pointing to the latest available revision.

~/snap/notepad-plus-plus$ ls -la
total 20
drwxr-xr-x   5 igor igor 4096 Apr 28 16:13 .
drwxr-xr-x 133 igor igor 4096 May 26 15:29 ..
drwxr-xr-x   5 igor igor 4096 Feb 26 14:45 258
drwxr-xr-x   5 igor igor 4096 Apr 28 16:13 260
drwxr-xr-x   6 igor igor 4096 Jan 12 14:43 common
lrwxrwxrwx   1 igor igor    3 Apr 28 16:13 current -> 260

Important details regarding user data and home access

There are several notable exceptions to user data access that are not immediately apparent from the use of the COMMON and DATA directories.

• By default, snaps are strictly confined. A strictly confined snap cannot access any system resource, like home, network, USB devices, camera, audio, etc. Publishers who want to grant their snaps access to specific resources must use interfaces, which then allow granular access to these resources. One of the available resources is the user’s home directory.
• A snap with a declared home interface will then have access to the user’s home directory, but only to regular files and folders. Please note, hidden files will not be accessible by default, and they require specific security overrides for that snap in the Snap Store. If you’re a developer or a publisher, you can request the additional paths for your snap in a forum request.
• The home interface is auto-connected on classic systems. It is not auto-connected on Ubuntu Core.
• Snaps without the home interface declared and/or connected cannot access the disk. The SNAP_USER_DATA directory will still be created and exist in the user’s home directory. However, it will contain no files.

What happens when you delete a snap?

If you decide to remove a snap from your system, the following will happen:

• The snap will be unmounted and no longer shown under /snap.
• The data under /var/snap/”snap name”/ and /home/”username”/snap/ will be deleted. However, a copy will be retained as a snapshot for 30-days (except on Ubuntu Core systems), allowing you to restore the data, or manually retrieve it in case you need it. The location for snapshots is under: /var/lib/snapd/snapshots/.

You can use the built-in snapd snapshot management functionality to restore data, or unzip the archives, and only copy the data you consider necessary. If you have 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

Other locations

There are several other directories you should be aware of:

• /var/lib/snapd/cache – Working cache, to minimize download size and speed up refreshes.
• /var/lib/snapd/snaps – Contains all the versions of snaps installed on your system.

Summary

Snap data management is different from the classic Linux conventions. To that end, both the developers and the users should pay attention to the finer nuances, so they can get the best experience. Developers should make sure they correctly utilize the necessary and available paths, and build their snaps so they store important information in locations that will be backed up on maintenance operations. Users should note the difference between their classic Linux home and snap home.

Hopefully, this article clarifies some of the less obvious questions and topics around snap data management. If you have any suggestions or comments, please reach out on our forum, and let us know.

Photo by Ricardo Gomez Angel on Unsplash.