Interface management


When a snap needs to access a resource outside of its own confinement, it uses an interface. Interfaces enable resources from one snap to be shared with another.

Interfaces are commonly used to enable a snap to access OpenGL acceleration, sound playback or recording, your network and your $HOME directory. But which interfaces a snap requires, and provides, is very much dependent on the type of snap and its own requirements.

Most users don’t need to worry about interfaces. Snaps are designed for strong application isolation and safe interface connections are made automatically.

To see which interfaces a snap is using, type snap interfaces <snapname>:

$ snap interfaces vlc
Slot                     Plug
:desktop                 ffmpeg,spotify,vlc
:home                    ffmpeg,spotify,vlc
:network                 ffmpeg,lxd,spotify,vlc
:opengl                  ffmpeg,spotify,vlc
:optical-drive           ffmpeg,vlc
:pulseaudio              ffmpeg,spotify,vlc

See Supported interfaces for a comprehensive list of interfaces supported by snap.

Slots and plugs

An interface consists of a connection between a slot and a plug. The slot is the provider of the interface while the plug is the consumer, and a slot can support multiple plug connections.


In the previous output (see above), the left column lists the slots that the VLC snap is using, while the right column lists the snaps plugged into the slots. FFmpeg, Spotify and VLC are all accessing the system-provided network interface slot, for example, giving them all network access.

Manual connections

An interface may be automatically connected when the snap is installed, or manually connected at some point after installation.

To list all currently registered interfaces, along with their slots, plugs and current connections, use the snap interfaces command with no further arguments:

$ snap interfaces
Slot                             Plug
:alsa                            -
:pulseaudio                      ffmpeg,spotify,vlc
-                                ffmpeg:alsa

Interfaces provided by the system begin with the : (colon) symbol and are implemented by the Core snap, such as with :alsa in the above output. For a slot to be visible, and connectable, its corresponding snap needs to be installed.

To view which snaps provide connectable slots and plugs, use the snap interface <interface name> command:

$ snap interface alsa
name:    alsa
summary: allows access to raw ALSA devices
  - ffmpeg
  - core

To make a connection, use the following syntax:

$ snap connect <snap>:<plug interface> <snap>:<slot interface>

A slot and a plug can only be connected if they have the same interface name. For example, to connect FFmpeg’s ALSA plug to the system’s ALSA slot, you’d enter the following:

$ sudo snap connect ffmpeg:alsa :alsa

To disconnect an interface, use snap disconnect:

$ snap disconnect <snap>:<plug interface> <snap>:<slot interface>

Following our previous example, you could would disconnect ffmpeg:alsa with the following command:

$ sudo snap disconnect ffmpeg:alsa :alsa

ⓘ A successful connection grants any necessary permissions that may be required by the interface to function.

Supported interfaces
Home folder folder permissions
Security policy and sandboxing
Adding OpenGL/GPU support to a snap
Command line utility needs read access to file in current dir
The unity8-calendar interface
The unity8 interface
The uhid interface
The udisks2 interface
The ubuntu-download-manager interface
The tpm interface
The timezone-control interface
The timeserver-control interface
The time-control interface
The thumbnailer-service interface
The system-trace interface
The system-observe interface
The storage-framework-service interface
The ssh-public-keys interface
The ssh-keys interface
The spi interface
The snapd-control interface
The shutdown interface
The serial-port interface
The screen-inhibit-control interface
The removable-media interface
The raw-usb interface
The pulseaudio interface
Getting started
The process-control interface
The ppp interface
The physical-memory-observe interface
The physical-memory-control interface
The password-manager-service interface
The optical-drive interface
The openvswitch-support interface
The openvswitch interface
The opengl interface
The online-accounts-service interface
The ofono interface
The network-status interface
The network-setup-observe interface
The network-setup-control interface
The network-observe interface
The network-manager interface
The network-control interface
The network-bind interface
The network interface
The netlink-connector interface
The netlink-audit interface
The mpris interface
The mount-observe interface
The modem-manager interface
The mir interface
The media-hub interface
The maliit interface
The lxd-support interface
The lxd interface
The log-observe interface
The location-observe interface
The location-control interface
The locale-control interface
The libvirt interface
The kvm interface
The kubernetes-support interface
The kernel-module-control interface
The juju-client-observe interface
The joystick interface
The io-ports-control interface
The iio interface
The i2c interface
The hostname-control interface
The home interface
The hidraw interface
The hardware-random-observe interface
The hardware-random-control interface
The hardware-observe interface
The gsettings interface
The greengrass-support interface
The gpio-memory-control interface
The gpio interface
The gpg-public-keys interface
The gpg-keys interface
The fwupd interface
The fuse-support interface
The framebuffer interface
The firewall-control interface
The dvb interface
The dummy interface
The docker-support interface
The daemon-notify interface
The can-bus interface
The calendar-service interface
The bool-file interface
The docker interface
The unity7 interface
The x11 interface
The wayland interface
Supported interfaces
The dbus interface
The desktop interface
The desktop-legacy interface
The dcdbas-control interface
The cpu-control interface
The cups-control interface
The core-support interface
The classic-support interface
The camera interface
The browser-support interface
The broadcom-asic-control interface
The bluez interface
The bluetooth-control interface
The avahi-observe interface
The avahi-control interface
The autopilot-introspection interface
The alsa interface
Snap Documentation
The content interface
The account-control interface
Parallel Installs
Snapcraft overview
Manual Review Requested - hub (classic confinement)
Snapcraft.yaml reference
Gtk-Message: Failed to load module "appmenu-gtk-module"
Minecraft launcher crashed in Debian
Home folder folder permissions
Using in-development features in `snapcraft.yaml`
Pulseaudio recording
Permission denied when trying to access user files
Snap Confinement
The device-buttons interface
Supported snap hooks
Snapcraft app and service metadata
Interface hooks
Access to NAS drive
Access to NAS drive
The accounts-service interface
The upower-observe interface
The unity8-contacts interface

Is it correct that for a Snap to operate in confined mode through an interface, that the app must somehow code against that interface? For example, if I have an X11 app would I code it against the Snap X11 wrapper, or just start using the X11 API directly?


It is important to note that ‘interface’ here is a snapd term, not to be confused with Application Programming Interfaces (APIs), Application Binary Interfaces (ABIs), DBus interfaces, etc. Your snapcraft.yaml/snap.yaml declares the snapd interfaces that your snap needs to use relevant programming interfaces for the resource. In your case, you declare ‘plugs: [x11]’ and then you are allowed to talk to the X server using the raw X protocol or any other higher level abstractions (eg, windowing toolkits like gtk, qt, etc).


Ok interesting, that is a little different than what I had expected. Doesn’t that leave the Snaps in the position of needing knowledge of the systems they’re deploying to? For example if I have a Snap that is requesting :network-setup-control don’t I need to know what network manager is installed?

Also, are there any good resources on writing against Snap interfaces for developers? This is pretty much the only link I can find and it’s hard to understand what exactly is being opened up when an app is connected to an interface.


Interfaces can be thought of as contracts between the slot side (the provider, sometimes its a service) and the plug side (the consumer). On an all-snaps system like Ubuntu Core, the snap executes in a predictable runtime where snapd exposes so-called ‘implicit slots’. Other slots are provided by app snaps (eg, a network-manager snap). In this manner, you only have to know what the slot implementation provides. It would be considered a bug in a providing snap to drop APIs, etc or otherwise break consuming snaps.

For so-called classic distributions where snaps are installed alongside debs/rpms, the above mostly holds true for strict and devmode snaps, though, yes, it is true that Fedora and Ubuntu might ship different network-managers as part of the system. Typically there isn’t a tight coupling between the client libraries and services (indeed, libraries like Qt have abstractions you program to and they figure out which network-manager DBus APIs are available), but where there is a tight coupling, the snap would have to account for that.

For ‘classic snaps’ which have no confinement and can access anything on the system directly, it is up to the snap publisher to account for any difference across distributions (which is made is by using libraries like the aforementioned Qt with network-manager).

/usr/bin/fold got permission denied but /usr/bin/fmt is working fine. What's happened?

I’ll defer to the snap advocacy team here (@evan, @Wimpress and @popey) but can say you can look at the snapd source code for the latest on what is allowed:


Ah ok actually that source is very helpful. So for the network_setup_control interface, it’s actually operated by files using netplan. And I guess network_bind operates by allowing system calls to accept/bind/listen? That seems doable.

Our current installation script uses authbind though. So much to learn. I’ll save it all for another thread though. It looks like the source is the place to go for good dev details on interfaces now.


Is it possible for a launcher (preferably, a shell script) to detect whether a certain interface is connected to a snap without detecting AppArmor denials?


You could try:


usage() {
    echo "Usage: check-plug <snap name> <interface name>"

if [ -z "$1" -o -z "$2" ]; then


if snap interface "$INTERFACE" | sed -e '1,/plugs:/d' | sed -e '/slots:/,$d' | awk '{print $2}' | grep "^$SNAPNAME\$" >/dev/null; then
    echo connected
    echo not connected

Edit: Just spotted that you want this inside the snap. I don’t know if that data is exposed to the application in a snap… I just checked snapctl, which doesn’t appear to expose the info, so you cannot do it through that.


Thanks for the info.


indeed you dont really need to “detect denials” but just check if you have the expected access to a file, device or whatever the interface normally provides.

#! /bin/sh

[ -r "/var/log/syslog" ] || echo "please connect log-observe !!"


I would like to found out how to assert plugs/slots and plugs & slots with attributes in this topic.


This topic used to have all the undocumented and new interfaces which are not yet updated in . I see they are no longer available here as well. Could you please add a link where we can find the updated interfaces list ?


We’re currently working on the Interfaces pages and we’ll definitely be adding the interface list back (likely today), along with a reference to each interface. Sorry this isn’t clear - when something like this affects the docs again, I’ll leave a ‘Work in progress’ note with an explanation.


The interface section is still not available. When can we expect it to be back ?


Have you seen Supported interfaces? It should include all the details there were previously in this topic, but let me know if there’s something missing.


Still broken here (18.04 LTS). The above steps do not resolve it.

The snap was ‘postman’ and my home folder is /home/local/SOMETHING/myname


So this page doesn’t seem to teach you how to add interfaces to your snapcraft file, and neither does:

The latter tells you what interfaces are supported, but neither of these docs seem to be linking me towards, as an author, how to do a strict mode snap and have it request interfaces.

The Go examples are both “devmode” snaps, and thus don’t do confinement (AFAICT).

Some of that seems to be described in:

but if you just start with “Creating a Snap” it seems to direct you immediately to the language-specific details, which at least for the Go ones, doesn’t direct you back.


We’re missing a huge chunk of the snapcraft lifecycle, including installation (in a central place), command syntax, confinement, adding interfaces, using plugins, tracking down dependencies, build override examples, scriptlets, troubleshooting and publishing.

All of the above are high priority (and what I’m currently working on), so we’ll have something published on here soon.