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 awsWhen you find a package you like, you install it using:
snap install aws-cliOh, and you delete ‘em with remove.
snap remove aws-cliThere. 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 writableAnd 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.confOk. 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 slackDive 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 slackAs 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.apacheYou can also use systemctl to manage snap service processes:
systemctl status snap.nextcloud.apacheIf your snap includes at least one service, you can view its logs using snapd:
snap logs nextcloudYou can also specify a particular service:
snap logs nextcloud.mysqlFor 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 443You 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=8080Snapd 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.