How to give snaps access to /somedir

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.

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

Just run the app as if it is not a snap \o/

So for example chromium

1. Use a menu editor eg. "Main Menu" to add a custom chromium "menu item" (this is what ubuntu uses to find apps when you press super+a) :
2. Set Name eg.: Chromium Unsnapped
3. Set Command: /snap/chromium/current/usr/lib/chromium-browser/chrome --user-data-dir=~/ChrUnsnapped --class="ChrUnsnapped" %U
4. Set an icon eg. Download a retro chromium logo
5. save/close
6. super+a (or Show applications icon at bottom left) find your new item and right-click to add to favorites

<rant>

I am so super frustrated with snap that I can't configure my personal /stf dir like I have been doing for 15 years. Thank goodness for this hack, seems I'm going to have to do this for every freeken snap app :'( .

Yeah I know it is bad, but until there is a whitelist configuration, this seems to be the only way for things to go back to normal. I really don't want to put my stuff in /home, /mnt, /media please don't hate your users.

</rant>

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.

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.