The mount-control interface

The mount-control interface allows the mounting and unmounting of both transient (non-persistent) and persistent filesystem mount points. The interface does not itself create or maintain mount points, but instead permits the snapped application or service to create and maintain its own.

This interface gives privileged access to the device.

Requires snapd version 2.54+.

Interface documentation:

See Interface management and Supported interfaces for further details on how interfaces are used.

Developer details

Auto-connect: no
Super-privileged: yes


  • persistent (plug): defines whether the mount can be persistent or not.
    Either true or false. Defaults to false.
  • type (plug): lists one or more acceptable filesystems for this mount.
    Example: [ext2, ext3, ext4]
  • what (plug): absolute path of what to mount using a matching wildcard.
    Example: /dev/sd*
  • where (plug): either an absolute destination path for the mount, or a starting reference to $SNAP_COMMON or $SNAP_DATA optionally followed by a path. Wildcards are also supported.
    Example: /media/$USER/**
  • options (plug, required): a list of one or more permitted options.
    Example: [rw, sync]
  • namespace (plug): either snap, for locations within the snap, host, for locations outside the snap, or auto to set the namespace according to the where pattern. Defaults to auto.

See AppArmor globbing syntax for details on how the pattern matching and wildcards work.

It’s the responsibility of the snapped application or service to create and maintain a mount point, using either of the following:

The snapctl mount command is the only option for creating a persistent mount point via its --persistent mount option.

Accepted filesystems

Most filesystem types which are supported by the host system are allowed by this interface, with a few exceptions.

The following filesystems are not accepted:

bpf, cgroup, cgroup2, debugfs, devpts, encryptfs, hugetlbfs, overlayfs, proc, securityfs, sysfs, and tracefs.

While other filesystems are accepted, the following filesystems are supported along with their respective filesystem-specific mount options (more on mount options below):

adfs, affs, aufs, autofs, btrfs, cifs, ext2, ext3, ext4, fat, functionfs, fuse, hfs, hpfs, iso9660, jfs, msdos, nfs, nfs4, ntfs, ntfs-3g, lowntfs-3g, ramfs, reiserfs, squashfs, tmpfs, ubifs, udf, ufs, umsdos, usbfs, vfat, xfs, and zfs.

Note: If only tmpfs is specified, what must be none.

Permitted mount options

The following filesystem-independent mount options are permitted:

async, atime, auto, bind, defaults, diratime, dirsync, iversion, lazytime, noatime, noauto, nodev, nodiratime, noexec, nofail, nogroup, noiversion, nolazytime, nomand, noowner, norelatime, nosuid, nostrictatime, nouser, nousers, relatime, ro, rw, strictatime, and sync.

Note: Option bind is only allowed when no filesystem is specified.

Filesystem-specific mount options are also permitted, so long as each is supported by every filesystem listed in the corresponding type section. The mount options supported by a given filesystem can usually be found in its respective manpage or in the mount manpage. The complete list of supported filesystem-specific mount options for each filesystem type is included in the source code for this interface.

Code examples

  interface: mount-control
  - what: /dev/sd*
    where: /media/**
    type: [ext2, ext3, ext4]
    options: [rw, sync, user_xattr]
  - what: /usr/**
    where: $SNAP_COMMON/**
    options: [bind]
  - what: /dev/sda{0,1}
    where: $SNAP_COMMON/**
    options: [ro]
  - what: /dev/sdb[0-1]
    where: $SNAP_COMMON/{foo,other,**}
    options: [sync]
  plugs: [mntctl]

The test code can be found in the snapd repository:

The source code for the interface is in the snapd repository:

This might be giving the impression that the wildcard is mandatory; I would rather just spoecify that wildcards are supported.

I’m not sure if he have a nice way to present it in the docs, but in case we do, then please add a reference to man 8 mount.

Please replace the last entry /dev/sda[0-1] with /dev/sdb[0-1], as otherwise someone might get confused and think that the same entry should be specified twice.

Somewhere in the page we should also document the pattern rules, because they are AppArmor regular expressions, and not the usual Perl ones. See [](the AppArmor documentation for the syntax), just ignore the last two points because that’s only a proposed syntax.

Thanks for the feedback! I’ve updated the doc.

Thanks, Graham! Sorry for not noticing this earlier, but there’s something else:

Actually, this tells whether the mount can be persistent or not. One thing that we should make clear is that this interface by itself does not create any mounts: it only lists what is allowed. The application itself is responsible for creating the mount points it needs, either via using the /bin/mount command, the mount() system call, or the new snapctl mount command. In particular, in order to create a persistent mount point, the only option currently available is using the latter command, and passing the --persistent option. You can see an example of that in our tests. The snapctl mount command works similarly to the command-line mount command (that is: “snapctl mount -o <options> -t <fstype> </path/to/device> </target/mount/puint>”). Also, there is a corresponding “snapctl umount </path/to/mount/point>” command.

Thanks for the extra info! I’ve updated the doc and added the mount and umount commands to Using the snapctl tool.

1 Like

Thanks Graham, this looks very good to me! :slight_smile:

1 Like

Is there a reason why “snapctl --help” doesn’t mention this command? It seems like there’s a lot of this – new functionality being added to various commands but not being added to online help.