Managing Ubuntu Snaps: the stuff no one tells you

The snapcraft.io site: where snap developers and users meet

Canonical’s Snaps are definitely the real deal. The secure and portable Linux package management system is more than a geeky tool for showing off your tech creds. Just consider the growing list of companies that have already bought in and are providing their desktop software through snaps, including Blender, Slack, Spotify, Android Studio, and Microsoft’s (Microsoft!) Visual Studio Code. And don’t forget that the real growth of the snap system is in the world of IoT devices and servers rather than desktops.

But as the popularity of snaps grows — some new Linux distros come with the snapd service installed by default — you might be forgiven for wondering how you’re supposed to make them work. Don’t get me wrong: there are all kinds of web-based guides for finding, installing, and removing snaps. And there are places developers can go for help building their applications as snaps. But right now I’m talking about configuring their behavior or troubleshooting when things go wrong.

Just for the record, you search for new snaps to install using something like:

$ snap find aws

When you find a package you like, you install it using:

$ snap install aws-cli

Oh, and you delete ‘em with remove.

$ snap remove aws-cli

There. You can’t say I never taught you anything. But that’s not what this article is about. What we are going to talk about is real management stuff, like changing configurations or troubleshooting things that broke.

Understanding the snap file system

Well, how’s that going to be different from the way you’d normally do it on Linux? Configuration files are usually going to be in /etc/, processes will reveal their deepest secrets through systemctl, and logs will find their way to /var/log/.

Not so fast there, pilgrim. That’s not always how things work in Snapland. You see, a snap is really nothing more than a single compressed file (named using the .snap extension) containing the entire file system needed for running a package. These files are never actually decompressed and “installed,” but are mounted dynamically at run time and exposed to the user as a virtual environment.

This means that the resources used by a program might not actually exist on the host system. Thus, for example, the Nextcloud snap creates its own versions of Apache and MySQL for its backend. So if, say, you want to configure a new virtual host in /etc/apache2/sites-available/ or create a new MySQL user the traditional way, you’re out of luck.

The advantages of this approach are significant: installation and setup will generally be much smoother and you’re far less likely to run into dependency issues and conflicts. But it also at least appears to mean that you get less access to the vital organs that power your software.

So, then, where does everything snappy happen? Take a look through your host file system for yourself: you’ll probably find more snap directories than you can shake a stick at (should you be so inclined). Here are the directories the snap install process probably created:

/snap/
/var/snap/
/var/lib/snapd/
/home/username/snap/

That many? What for? Let’s go through those one at a time. Feel free to poke around your own Linux machine to see all this for yourself.

The actual .snap files are kept in the /var/lib/snapd/snaps/ directory. When running, those files will be mounted within the root directory /snap/. Looking over there — in the /snap/core/ subdirectory — you’ll see what looks like a regular Linux file system. It’s actually the virtual file system that’s being used by active snaps.

$ ls /snap/core/current
bin   dev  home  lib64  meta  opt   root  sbin  srv  tmp  var
boot  etc  lib   media  mnt   proc  run   snap  sys  usr  writable

And here’s a subdirectory containing (read-only) configuration files used by the Nextcloud snap. That’ll only be there, of course, if you’ve installed Nextcloud (snap install nextcloud).

$ ls /snap/nextcloud/current/conf/
httpd.conf  mime.types  ssl.conf

Ok. Now what about /var/snap/? Very much like traditional inhabitants of /var/, the files within /var/snap/ contain various forms of user data and log files — the kind of data that’s generated and consumed by applications during operations. This example shows directories for data used by some desktop-related snaps, including the AWS CLI and the Slack team communication tool. (OK, technically speaking, the AWS CLI isn’t a desktop tool.)

$ ls /var/snap
aws-cli  core18           gnome-system-monitor  gnome-calculator
brave    gnome-3-26-1604  gnome-characters      gtk-common-themes
core     gnome-3-28-1804  gnome-logs            slack

Dive deep into the subdirectories within /var/snap/on your machine and see what you can discover.

That leaves just the ~/snap directory that exists in a user’s home directory on at least some Linux file systems. It’ll contain directories using some of the names you’ll see in /var/snap. What’s going on in there?

$ ls ~/snap
aws-cli  brave  gnome-calculator  slack

As far as I can tell, these directories are meant to store versioned data related to settings used by your user account.

Snap administration tools

So far I’ve shown you how to find various classes of data kept in configuration files (within /var/snap/), virtual file systems (/snap/), and collections of user settings (~/snap). I also showed you where not to look — /var/lib/snapd/ — which is where the .snap files themselves live; nothing to see here, move along now.

Now what about actual administration? This is a bit more complicated. Some snaps — like Nextcloud — expose a fully-featured admin interface. I talk about that in my Administrating Nextcloud as a Snap article. But it seems that the simplicity of snaps sometimes means that there just isn’t much hands-on configuration that’s possible.

However, that’s not always the case. But first, you’ll need to know about snap services. Some more complex applications require multi-layer software stacks. Nextcloud, for instance, creates and manages its own versions of Apache, MySQL, PHP, and Redis. Each one of those “layers” is, in snap terms, called a service.

If any snaps installed on your machine have their own services, you’ll be able to list them along with their status using this snapd command:

$ snap services
Service                    Startup  Current   Notes
nextcloud.apache           enabled  active    -
nextcloud.mdns-publisher   enabled  active    -
nextcloud.mysql            enabled  active    -
nextcloud.nextcloud-cron   enabled  active    -
nextcloud.nextcloud-fixer  enabled  inactive  -
nextcloud.php-fpm          enabled  active    -
nextcloud.redis-server     enabled  active    -
nextcloud.renew-certs      enabled  active    -

You can also control the run and startup status of a service. This example will stop Nextcloud’s Apache service and ensure that it doesn’t launch when the system reboots (although, just remember that this will disable Nextcloud — you probably don’t want to do that):

$ snap stop --disable nextcloud.apache

You can also use systemctl to manage snap service processes:

$ systemctl status snap.nextcloud.apache

If your snap includes at least one service, you can view its logs using snapd:

$ snap logs nextcloud

You can also specify a particular service:

$ snap logs nextcloud.mysql

For some snaps (like Nextcloud), snapd makes useful configurations available from the command line. You can display available settings using snap get:

$ snap get nextcloud
Key        Value
mode       production
nextcloud  {...}
php        {...}
ports      {...}
private    {...}

Drop down a level by adding the name of a specific setting. This example shows us that Nextcloud is currently listening on only ports 80 (HTTP) and 443 (HTTPS).

$ snap get nextcloud ports
Key          Value
ports.http   80
ports.https  443

You could change a setting using the set command. This one would tell Nextcloud to listen on port 8080 for insecure HTTP requests instead of 80.

$ snap set nextcloud ports.http=8080

Snapd also offers some system-wide configuration settings that are described here, documentation of environment variables is maintained here, and information on keeping your snaps updated can be found here.

All that’ll get you started when things need fixing. So get to it.

Looking for more? You might enjoy my books and Pluralsight courses on Linux, AWS, and Docker-related topics.