Can we adjust this section to indicate that a snap that was already installed before a snap was granted auto-connect for some interface (i.e. mount-observe), will be updated to use the new auto-connection when that is granted as per store processes? I.e. this is the expected workflow:
publisher pushes snap that plugs mount-observe w/o auto-connect from store
user installs the snap, mount-observe is not connected
publisher requests and receives auto-connect, snap declaration in the store is updated
at some point in the future, snapd downloads the new snap declaration for the snap and applies the new auto-connect.
There was some confusion from others about this point and I’m not sure how to succinctly summarize this point.
If your snap previously used pulseaudio when it was automatically auto-connected, then it will continue to do so, but new snaps will not get auto-connection of pulseaudio.
I answered this question over here: Electron Audio on Ubuntu Core. What is listed on this page is mostly about implicit slots or expected auto-connections for app-provided slots. The pulseaudio snap predates the audio-* interfaces and still allows auto-connecting to it. If/when it is updated, we can update its snap declaration to match the above.
Might it be useful to add a note to explain this documentation only applies to Classic? I assumed from reading it that it applied to all operating systems equally.
This page should talk about the cups interface as the new interface to enable your snap to print. I’m not sure if this is already supported on all distributions, though.
Weird leading hyphen on line for “kernel-module-load”
This list might not be complete, I can see in the source go files for polkit and scsi-generic interfaces which are not in this list, there might be others.
There is a bullet point paragraph describing the “Transitional interfaces” column, but no such column exists, and there is no other mention of “transitional” on the page. Should this bullet be removed now?
Thanks for mentioning this. There used to be a column for transitional interfaces, but this was removed some time ago. I’ve removed the bullet, but also added transitional interfaces to our Glossary so that the information isn’t lost.
A new interface, nfs-mount, has been added to snapd 2.62 that allows users to mount NFS shares within writable areas of their Snap. You can find the associated PR here. The syntax is very straightforward, as you only need to add nfs-mount to your list of plugs, unlike other mounting interfaces which require additional rules. Additionally, the userspace binaries required to actually mount shares are not included in base snaps, so they’ll have to be pulled in manually from the nfs-common package. I’ve appended a barebones example below of a Snap that could be used to mount and unmount a share within $SNAP_COMMON.
Note: This interface only supports NFSv4, since other version of NFS require additional daemons to be present and running. This shouldn’t be an issue in practice, however, since NFSv3 and prior are extremely old at this point, and it’s unlikely that they’re being used by the vast majority of people.
Snapcraft.yaml
name: nfs4-example
base: core22
version: '0.1'
summary: Example Snap showing off the new nfs-mount interface.
description: |
This snap provides two commands: nfs-mount and nfs-unmount.
Mount takes a single argument in the form of <hostname>:<nfs-share-name>.
grade: stable
confinement: strict
apps:
nfs-mount:
command: bin/nfs-mount.sh
plugs: [nfs-mount]
nfs-unmount:
command: bin/nfs-unmount.sh
plugs: [nfs-mount]
parts:
scripts:
plugin: dump
source: ./src
organize:
'*': bin/
packages:
plugin: nil
stage-packages: [nfs-common]
nfs-mount.sh
#!/bin/sh -eux
# If not argument is provided, print help and exit
[ -n "$1" ] || {
printf '%s <hostname>:<nfs-share-path>\n' "$0"
exit 1
}
# Ensure that the mount point has been created
[ -d "${SNAP_COMMON}/mnt" ] \
|| mkdir -p "${SNAP_COMMON}/mnt"
# Attempt to mount the share
mount.nfs4 "$1" "${SNAP_COMMON}/mnt"
