89

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.

  • 2
    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 07 '18 at 22:22
  • 5
    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 07 '18 at 22:28
  • 5
    Is there any ticket/bug/feature-request open for snap? I would like that feature too! – kravemir Aug 18 '18 at 16:53
  • 1
  • 1
    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: https://snapcraft.io/docs/interface-management – Daniel Murray Feb 29 '20 at 09:57
  • 7
    After dealing with this type of problems, my BIG suggestion get rid of snaps, really is not snap who should decide what directories I the owner and admin of the Machine and OS can or cannot use, for me is like limiting grep functionality by not allowing to search some words, really disappointed with snap. – tonio Apr 08 '21 at 17:43
  • TL;DR: You can't. Bad design, not user-focused. – Alfonso Nishikawa May 10 '23 at 17:32

6 Answers6

47

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

  • 7
    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
  • @ZygmuntKrynicki or under /mnt, if removable-media interface has been connected for the snap. – jarno Oct 05 '19 at 17:15
  • 38
    @ZygmuntKrynicki I am astonished too. The default mount points should be configured through a config file and not enforced. – markhor Nov 22 '19 at 09:12
  • 40
    @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 07 '20 at 16:20
  • 9
    @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 04 '20 at 07:01
  • 8
    @ZygmuntKrynicki: what about people who mount encrypted volumes at paths like /veracrypt ? Is it just impossible to whitelist a path? – Dan Dascalescu May 14 '20 at 23:25
  • 11
    @ZygmuntKrynicki — hard-coding has been deprecated, for excellent reasons, since at least the early 1980's (maybe earlier). Please would you consider using a config file. This is causing serious issues for some of us. – Paddy Landau Sep 21 '20 at 12:26
  • Good question, but to be honest this answer is not the answer to it. It looks like SNAP is doing security by obscurity at its best. – Thomas Mar 24 '22 at 11:59
  • 2
    Idea: lets make this work similar to Docker, where you can explicitly make volumes or folders available to the container. When I run snap I can do snap --allow-write /foo/Movies, or whatever I want to do. – Hugh Perkins Dec 26 '22 at 11:26
  • 2
    (Like, why would I want a snap to be able to read/write my entire home folder anyway? What's the point of 'limiting permissions', and then giving it access to all my data! :O ) – Hugh Perkins Dec 26 '22 at 11:31
  • I reckon there's an opportunity for someone to create something that can read and run snaps, but with better control over permissions. Sure, sooner or later, snap team might incorporate that idea into their own work. But given the resistance to change we are seeing, you might have already taken over 50% of userbase market share before they did that. – Hugh Perkins Dec 26 '22 at 11:32
  • 2
    @HughPerkins: No parenthesis needed needed on your comment. One more illustration of the rediculousness of the hardcoding argument. – Peter V. Mørch Dec 27 '22 at 05:25
  • It's sooo stupid how they did it. There is no reason to defend having it hardcoded. – Alfonso Nishikawa May 10 '23 at 17:34
  • While this post is correct, it is not the answer. Scroll down to https://askubuntu.com/users/184404/kat-amsterdam to get reasoning and a solution. – user3054986 May 18 '23 at 09:51
  • @ZygmuntKrynicki I have my photos disk mounted at /photos and I want them exactly there (that's not only about preference but about sharing this dir with my wife). So now I can't save photo I got via WhatsApp because somebody arbitrarily decided which directories are OK and which are not. Not sure who invented concept to protect /some/random/dirs while giving full access to /home but we have Unix permissions system which works perfectly well and let us clearly denote perms. Want to be stricter? OK, let me grant perms to some group or user to mark what snaps can do. – Mekk Nov 07 '23 at 14:48
14

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 enter image description here

<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>

AmanicA
  • 1,749
  • 1
    I don't understand what you did. How does this setting makes any difference? Can you open a file in /tmp with Chromium for example? – leogama Feb 11 '21 at 22:01
  • Yes I can access my real /tmp with my unsapped chromium. You can try running the command /snap/chromium/current/usr/lib/chromium-browser/chrome --user-data-dir=~/ChrUnsnapped --class="ChrUnsnapped" %U manually on the commandline. The rest is just to create an launch icon. – AmanicA Feb 13 '21 at 00:31
  • 4
    Ok, just to clarify: going this path, we are explicitly bypassing Snap confinement and running the app with standard user permissions. It won't read/write to files (settings, cache, etc.) in ~/snap/appname/{common,current}/ but in its default locations inside $HOME. There's no problem in doing it —I use it for Chrome SSB—, however you need to understand what are you doing. – leogama Sep 18 '21 at 14:48
  • 2
    I guess this doesn't work with newer snap, which just symlinks binaries to /usr/bin/snap itself? – rogerdpack Jan 18 '22 at 17:42
  • Awesome, at least some way to run a snap app... – LetynSOFT Oct 03 '22 at 19:54
  • yeah, snap sucks as you said. and your solution is brilliant, @AmanicA

    e.g to run skypeforlinux w/o using snap, which is no longer supported other than via snap, just run /snap/skype/current/usr/share/skypeforlinux/skypeforlinux - priceless!

    I also had to change echo 256 | sudo tee /proc/sys/fs/inotify/max_user_instances

    – stason Feb 10 '24 at 03:36
10

So, two things.

First: Linux and Unix have a Filesystem Hierarchy Standard which Ubuntu and Snaps follow. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Second: If one chooses to deviate from the worldwide standard that has been in place since 1979, that's perfectly fine, but then bind mount your non-standard directory so that snap can find it.

mount --bind /nonstandard_mountpoint /media/$USER/directory

or

mount --bind /nonstandard_mountpoint /home/$USER/directory

then you can continue to use your nonstandard mountpoint AND at the same time all your snaps can find your nonstandard_mountpoint data.

It's even possible to make this mount permanent by adding it to your FSTab

sudo nano /etc/fstab

append the line

/source /destination none defaults,bind 0 0

to save and exit

CTRL+X y

here is an example: Music files stored at /srv/dsmusic

first create a directory at /home/$USER/Music/dsmusic

mkdir /home/$USER/Music/dsmusic

then bind mount /srv/ds music to that directory

sudo mount --bind /srv/dsmusic /home/$USER/Music/dsmusic

Then all your snap music programs will auto magically find the music files.

to contine the Music example:

sudo nano /etc/fstab

append the line

/srv/dsmusic    /home/username/Music/dsmusic    none    defaults,bind    0 0

** Unmounting **

if you want to unmount you can use the regular umount command like a regular mountpoint

sudo umount /home/$USER/Music/dsmusic

For more information please see: https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount

SystemD

** Please note that there is a more modern way to do this in SystemD instead of using fstab.

To create bind mounts in SystemD you need to create a .mount file with the path to the nonstandard mountpoint separated by - (minus) instead of forward slashes (/)

sudo systemctl edit --full --force path-nonstandard.mount

past the following and edit the mountpoints

[Unit]
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target

[Mount] What=/some/old/dir Where=/the/new/dir Type=none Options=bind

[Install] WantedBy=local-fs.target

if nano is the default editor CTRL+X y (for nano) :wq (for vim)

enable the systemD file

sudo systemctl enable path-nonstandard.mount

then reload the SystemD daemon

sudo systemctl daemon-reload

Then start your mount with

sudo systemctl start path-nonstandard.mount

If you need to modify it again just

sudo systemctl edit --full path-nonstandard.mount

Example: To use the Music example again:

sudo systemctl edit --full --force srv-dsmusic.mount

this will open a blank editor and create a new .mount file in the correct system folder to which one adds the lines

for a local mountpoint on the same hardware:

[Unit]
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target

[Mount] What=/srv/dsmusic Where=/home/username/Music/dsmusic Type=none Options=bind

[Install] WantedBy=local-fs.target

please note that if your non-standard mountpoint is a NAS or other remote device you'll need to use remote-fs.target and not local-fs.target

for a remote mountpoint on different hardware such as a NAS

[Unit]
DefaultDependencies=no
Conflicts=umount.target
Before=remote-fs.target umount.target

[Mount] What=/srv/dsmusic Where=/home/username/Music/dsmusic Type=none Options=bind

[Install] WantedBy=remote-fs.target

then exit the editor CTRL+X y (for nano) :wq (for vim)

enable the systemD file

sudo systemctl enable srv-dsmusic.mount

Then reload the systemD daemon

sudo systemctl daemon-reload

then start your new mountpoint

sudo systemctl start srv-dsmusic.mount

to unmount the bindmount just

sudo systemctl stop srv-dsmusic.mount

You now be able to find mirrors of your data at /srv/dsmusic as well as snap will be able to find the same data at /home/$USER/Music/dsmusic

for more information please see: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdBindMountUnits and https://www.freedesktop.org/software/systemd/man/systemd.mount.html

Kat Amsterdam
  • 2,721
  • 1
  • 17
  • 17
  • 3
    I have a doubt, that maybe you could squeeze into your answer: if /mnt is for temporary mounts, and /media is for removable media. What's the standard place to mount an extra hard drive that is not part of the system installation, but it's shared with a couple of users? I'd like to know, specially when the user home is encrypted and not mounted until log in. – Emilio Feb 28 '22 at 21:15
  • This should be the accepted answer. The SNAP's restriction is intentional, it's meant to enforce the adoption of the FHS. Yet, it doesn't prevent the user from accessing external directories from such user's home folder, provided that source and destination are bind-mounted as you explained. Well done. – Yuri Sucupira Nov 20 '22 at 15:55
  • 1
  • 2
    Snap is super user-friendly, no doubt. – Alfonso Nishikawa May 10 '23 at 17:13
  • 2
    I think this answer completely misses the point. The should be user configurable. E.g. I might want to give LibreOffice access to /mnt/super-secret-project, but not VLC. That is also not possible. – Peter V. Mørch May 25 '23 at 07:54
  • 1
    "In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans. For tooling, writing mount units should be preferred over editing /etc/fstab." -- man systemd.mount – sourcejedi May 25 '23 at 19:14
  • First: Linux has permission system which we happily use, understand, and which has rich tooling. Instead, somebody decided he or she knows better where we want our files and which our files need protection more than others and hardcoded that. So I try to save file and get mysterious file saving window where my home silently skips symlinks and where most bookmarks don't work. Sorry for rant but I lost an hour again. Going to remove all snaps and install debs or flatpaks. – Mekk Nov 07 '23 at 15:32
3

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.

  • 15
    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
  • 25
    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
  • 6
    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
  • 3
    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 07:43
  • @PeterV.Mørch you could mount or move those files under /mnt, make sure removable-media interface has been connected for the snap, and create symlinks in the original locations, if you want. – jarno Oct 05 '19 at 17:28
  • 9
    @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
  • 1
    Huh? That didn't work for me. If I put a file in /mnt/ost.txt, snap gedit can open it fine after: sudo snap connect gedit:removable-media :removable-media. But not if I i move it to: /media/ost.txt (which seems to contradict the documentation). But making /mnt/ost.txt a soft link to /ost.txt does not work either. (Which would also be an enourmous security problem if it did) – Peter V. Mørch Mar 04 '20 at 15:58
  • @PeterV.Mørch oh that did not work for me either in 18.04. But files under `/media/$USER" can be used. BTW I did not get any notification, because you did not refer to me. – jarno Mar 10 '20 at 21:15
  • @jarno: As I wrote in the OP: "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." – Peter V. Mørch Mar 11 '20 at 04:52
  • @PeterV.Mørch sorry, I do not remember why I thought symlinking directories would work. – jarno Mar 11 '20 at 12:44
  • 8
    @Zygmunt Krynicki - Given that "everyone loves to customize their filesystem", this shows how undesirable it is to use snap modules. As a system administrator, I see no advantage, whatsoever, in utilizing snap modules, except perhaps for a few very specialized utilities. Using snap for general-purpose programs such as media viewers, file browsers, etc. requires massive reconfiguring of existing systems and lots of redundant file copying. And there is no positive advantage to that, other than being able to use some snap module which Ubuntu is now *forcing* us to install. – HippoMan Oct 25 '20 at 20:19
  • 1
    I'm not even customizing my filesystem, I just like using /dev/shm for temporary work I don't want to commit to SSD... – Michael Aug 19 '21 at 18:11
  • 2
    I still don't get why I can use docker run's -v option to mount arbitrary directory on any docker image from the internet but it's not possible for snaps. It's the same underlying technology and the same issues. What's the difference here? – pkubik Aug 23 '21 at 22:17
  • @PeterV.Mørch I'm with you: there should be a simple app to configure snap, where you see your snaps and you configure more locations. Simple and neat. – Alfonso Nishikawa May 10 '23 at 17:15
  • Does this mean that a snap application cannot possibly ever access a file which is a. stored on ZFS (following ZFS naming convention which does not use /media or /mnt for the mount point) and b. too large to be copied into RAM or onto the small boot disk of the machine holding /home? Why was it technically necessary to exclude symlinks (and according to https://askubuntu.com/a/1096079/54298, bind mounts) in this restriction? – nanofarad Oct 02 '23 at 21:53
1

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.

muru
  • 197,895
  • 55
  • 485
  • 740
ThorSummoner
  • 3,222
  • 3
  • 22
  • 31
  • 6
    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
  • 2
    Copying files into some snap installation also defeats the purpose of having secure drives like Veracrypt. – Dan Dascalescu May 14 '20 at 23:28
  • 8
    @ThorSummoner - Having to now utililze these copy utilities simply in order to make use of snap-based programs is a huge waste of time, effort, and hardware resources for users and system administrators. The fact that Ubuntu is no longer permitting us to download non-snap versions of certain programs forces us to do this extra work. And there is no advantage for end users or sysadmins to performing these onerous tasks. In this sense,snap is self-defeating, because it encourages users and admins to *not* use it, and to switch to distros which don't require it. – HippoMan Oct 25 '20 at 20:25
  • 6
    sudo snap remove --purge <app> && sudo apt install <app> – Matthieu Oct 26 '20 at 09:31
  • 2
    @Matthieu Should be the accepted solution! Though pretty sure that won't work on Ubuntu (at least) due to Canonical enfocing apt profiles to trigger a switch such that snap version of is installed anyway. Now I recommend users to install form the Debian repo, or perhaps use the burgeoning nix package manager EDIT: oops, didn't see HippoMan's comment above explaining the same thing – mikerover Dec 07 '20 at 16:23
  • recently I ran into a situation whee two snaps could be "allowed to talk" via a snap connect family of commands; I do not know if this broadens the range of usefulness to maybe "connect" a directory to a snap, if someone knows more, please let us know :) – ThorSummoner Dec 07 '20 at 19:59
  • There are files which cannot be copied, things like unix sockets, which I found extremely frustrating when trying to use snap workbench to connect to a mysql server exposed via unix socket (I did not find any way to make this work and resorted to using the mysql cli to continue) – ThorSummoner Dec 07 '20 at 20:05
  • 1
    It's 2021 and mount --bind with a target location readable by the snap app works for me. snapd version 2.48.3 on Ubuntu Desktop 20.04 – leogama Feb 11 '21 at 22:36
0

There are some other options if you get desperate:

  1. Use the unsnap utility - a bit alpha/bleeding-edge but can be done on Ubuntu
  2. Use the flatpak-remix - can be useful if you are doing a new install, but note it not an an official flavor :'(
  3. Try out linux-mint, debian or Pop!_OS - If you are keen to try a different distro like others are doing to get rid of snaps.
AmanicA
  • 1,749