The system-files interface

system-files provides access to the specified files in the system that are available in the snap’s runtime environment (eg, files in /etc). This interface gives privileged access to system data.

Auto-connect: no

  • read (plug): list of files and/or directories for read-only access (eg, ‘read: [ /etc/file-read, /etc/dir-read ]
  • write (plug): list of files and/or directories for read/write access (eg, ‘write: [ /etc/file-write, /etc/dir-write ]

Transitional: no. Requires snapd version 2.37+.

This interface is typically used for providing read-only access to system configuration directories to snaps that are the clear owner of the directory in order to support importing from existing applications. Importantly, this interface should not be used as a means to give access to system files where the snap is not the clear owner (eg, /dev, /proc, /sys, /usr, etc). Consumers of this interface require a snap declaration for distribution via the Snap Store.

While system-files can be used to share data with another snap, such as within a configuration file, this behaviour is not recommended. The content interface should be used instead.

An additional requirement for acceptance in the Global store is using a descriptive interface reference for use with snap connections|interfaces|connect|disconnect. For example, the ‘foo’ application is packaged as a snap and the snap publisher wants to import existing configuration from /etc/foo into the snap. The snapcraft.yaml might be:

name: foo
    interface: system-files
    - /etc/foo

    - config-foo

With the above, a snap connect command would look like: snap connect foo:config-foo.

ⓘ This is a snap interface. See Interface management and Supported interfaces for further details on how interfaces are used.

1 Like

Is this currently enabled in the daily ppa version of snap/snapd or have I jumped the gun?
I know the version on that states 2.36.3+git1072.d69ac16~ubuntu18.04.1 (and not 2.37) but the git sha its built from at least mentions system-files :slight_smile:

I’m trying it out but I get the error from my service that the path does not exist.

i.e. I have in my snapcraft.yaml

      - /var/lib/veebers
      - /var/lib/veebers

I install snapd from the daily ppa and install my snap (using --dangerous etc.)
I sudo mkdir /var/lib/veebers/ set the config to use that path and start the service where it fails with the complaint about the path not existing.

snap version gives:

snap    2.36.3+git1072.d69ac16~ubuntu18.04.1
snapd   2.36.3+git1072.d69ac16~ubuntu18.04.1
series  16
ubuntu  18.04
kernel  4.15.0-42-generic

This directory doesn’t exist in the snap’s runtime environment. The system-files interface is only really going to be useful for when directories from the host are passed into the snap, such as /etc. I suggest looking at the layout feature for your use case.


Sorry I should have been clearer in my original post (ugh, the /var/lib/veebers was a testing copy and paste, that should be /var/lib/juju).

I’m wanting the snap (in this case juju-db) to have access to /var/lib/juju where Juju stores bits and pieces (certs, the db dir etc.).
So in that case I think I do want system-files? (as it’s system directory access being granted to the snap, and not snap data being exposed as a system directory?)

While /var/lib/juju is a system directory, it is also not something that is passed into your snap’s runtime environment (use snap run --shell <your snap> and look for /var/lib/juju, it won’t be there). This interface is not about exposing arbitrary system locations into your snap; it is about allowing access to files that are already in the snap’s run time environment. I’ll update the description.

1 Like

Is there an example with system-files and other plugs? I can’t seem to get the syntax right on this;

  - network
  - network-bind
  - timezone-control
  - system-files:
    read: [/etc/somefile]
    write: [/etc/somefile]

When running snapcraft it gives the following error

Issues while validating snapcraft.yaml: The 'apps/my-app/plugs[3]' property does not match the required schema: OrderedDict([('system-files', None), ('read', ['/etc/somefile']), ('write', ['/etc/somefile'])]) is not of type 'string'

Any feedback is appreciated

Just wanna to double confirm that system-files interfaces can handle with /etc/modprobe.d/* ?

From a technical POV, yes, but from a process POV, maybe not. Perhaps create a new topic with more details as to why you need access to this directory?

1 Like