I'm just getting my feet wet with snap. I've installed vlc and want to try to use it. All my media is installed under /store, an NFS mount. And snaps don't allow access to that directory.

After googling I've come to understand that I can access files under /home/peter for the :home interface and /media for the :removable-media interfaces.

But I actually like /store and don't want to change that to be /media/store or /home/peter/store or anything else than /store.

Is there a way to get snap to allow my snaps (or perhaps just vlc) access to /store, so snap conforms to my naming conventions or am I forced to convert to snap's preferences?

That seems very inflexible, and I'm hoping there's something I've missed.

  • 1
    You could try removing the snap ( sudo snap remove vlc ) then reinstall with the classic option. May help, may not.. ( sudo snap install vlc --classic ) – doug May 7 '18 at 22:22
  • 2
    Thanks. I tried --classic and --devmode - neither worked. But also I want to give access explicitly to /store but not everything like /supersecret – Peter V. Mørch May 7 '18 at 22:28
  • 3
    Is there any ticket/bug/feature-request open for snap? I would like that feature too! – kravemir Aug 18 '18 at 16:53
  • This isn't the original problem, but if anyone else, like me, got here looking for how to give access to /media to a snap (for e.g. to use Darktable, which is basically useless without it) you can do it either through the snap-store interface, or by adding the removable-media 'plug' to your snap app on the command line. Some docs here: snapcraft.io/docs/interface-management – Daniel Murray Feb 29 at 9:57
  • @kravemir: See Launchpad issue 1643706 – Peter V. Mørch Mar 19 at 9:42

To my astonishment, it really looks like /home is hardcoded. mount-support.c contains:

    const struct sc_mount mounts[] = {
        {"/dev"},   // because it contains devices on host OS
        {"/etc"},   // because that's where /etc/resolv.conf lives, perhaps a bad idea
        {"/home"},  // to support /home/*/snap and home interface

Wow. That astonishes me. But there you have it.

Edit: See also Launchpad issue 1643706

| improve this answer | |
  • 1
    Hey, snapd developer here responsible for that code. To your astonishment that's actually the right thing to do. We cannot replicate the host filesystem and any of the random directories it may contain. While you may use /store someone else may use /stash or /whatever and there's no way to make that work in general. My recommendation is to simply mount your media in the location you desire, either in /home/... or in /media. Then it will fall under existing systems that manage that data and things should work correctly. – Zygmunt Krynicki May 25 '18 at 15:12
  • 13
    @ZygmuntKrynicki I am astonished too. The default mount points should be configured through a config file and not enforced. – markhor Nov 22 '19 at 9:12
  • 14
    @ZygmuntKrynicki Thanks for popping in and explaining that the code does what you intend. I respectfully and totally disagree with what you write. Hard-coding paths is very poor practice and cannot be meaningfully justified, even in the name of security. It's just basic inflexibility. – Stéphane Gourichon Feb 7 at 16:20
  • 1
    @ZygmuntKrynicki no one is asking to replicate arbitrary paths. The general solution to specific situations, though, would seem to be configuration rather than hardcoding, no? – 0xC0000022L May 4 at 7:01
  • 1
    @ZygmuntKrynicki: what about people who mount encrypted volumes at paths like /veracrypt ? Is it just impossible to whitelist a path? – Dan Dascalescu May 14 at 23:25

So to expand on my mini-answer above, there's no way to do that that is general, safe and sound. I know everyone loves to customise their filesystem but that has some cost and this is one of them.

Eventually, through the work on XDG portals, certain applications (especially graphical applications) can get access to files in arbitrary places iff said applications use some of the recently introduced GTK APIs. This will, when running under confinement, reach out to a trusted helper, pop up trusted UI that looks like a file picker, talk to a special FUSE filesystem to expose the file (at whatever location) as a special thing in /run/... somewhere that the application sees and things may work out fine.

This is designed for file-picker friendly things like media players or word editors. Your linux tree hosted at /codez won't work so well though.

| improve this answer | |
  • 7
    Hi Zygmunt, thanks for answering. My astonishment stands. You say: "I know everyone loves to customise their filesystem but that has some cost and this is one of them." Just so I understand: You realize but choose to ignore that this is a common thing to want to do? I'm not aware of any other costs for this naming convention over the last 15 years. – Peter V. Mørch May 29 '18 at 18:49
  • 9
    Is there any reason why one couldn't put a line like extradirs=/store:/other/location or something in /etc/snapd.conf or /etc/snapd/conf.d/vlc.conf. Just like tons of other linux applications out there. It seems to work fine for e.g. Docker. This is as if apache were to hard code DocumentRoot /var/www. – Peter V. Mørch May 29 '18 at 18:51
  • 5
    I do however, really appreciate your taking the time to write here, Zygmunt. Thank you. – Peter V. Mørch May 29 '18 at 18:53
  • 2
    It's not so easy. The main problem is not apparmor but actually the fact that at runtime the application is running in a different root filesystem. From that process point of view /store doesn't exist - it's not that it is not mounted, it's just not a directory at all. What snap-confine is doing is bringing some paths from the host system into the application mount namespace. Since the root filesystem in snaps is read only we cannot easily inject new mount points (e.g. for /store). – Zygmunt Krynicki May 30 '18 at 7:43
  • 3
    @jarno: Please read the OP: "I actually like /store". I know I can move or perhaps remount my files to where snap likes, but I don't want to. – Peter V. Mørch Oct 20 '19 at 21:51

mounting the target directory into /home/*/snap/ is mentioned as an option; a simple bind mount didn't work for me, neither did a hardlink, or a symlink of either the target files or directories into proposed snap directory, or any subdirectory thereof. This limitation could be due to the target files existing outside of a /home/*/ directory, I didn't test mounts/hard/symlinks to files within the /home/*/ prefix glob.

However, A Workaround: a full file copy into /home/<myuser>/snap/<appname>/<somenewdirectory> did work for me. Maintaining full dataset copies was yet infeasible for me, but there are plenty of tools to help deal with such a constraint; a manual recursive copy before using the snap, and copying the modified files back after is an option if your dataset is small or even atomic

To name a few file copying utilities that could help you:

  • cp --verbose --archive --recursive /somedir ~/snap/somedir, and source/target vice versa
  • tar -C / -c somedir | tar -C ~/snap/ -xv is a tar based file copy example
  • rsync --archive /somedir ~/snap/somedir, rsync is popular and has many wrapper/extensions

  • any file based backup utillity (graphical example: grsync) should be usable since the whole goal is to duplicate the dataset forward and back as needed

  • git clones, possibly, however local clones by default use hardlinks so if you are using git to manage filesystem io into a snap, be cautious of the possibility that without disabling hard links at clone time, that git clone might be inaccessible to the snap.

  • 3
    This won't work in the common use case of a NFS-mounted multi-terabyte NAS drive. – Peter V. Mørch Apr 28 '19 at 20:11
  • Copying files into some snap installation also defeats the purpose of having secure drives like Veracrypt. – Dan Dascalescu May 14 at 23:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.