87

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.

7
  • 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 7, 2018 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 May 7, 2018 at 22:28
  • 5
    Is there any ticket/bug/feature-request open for snap? I would like that feature too!
    – kravemir
    Aug 18, 2018 at 16:53
  • 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: snapcraft.io/docs/interface-management Feb 29, 2020 at 9: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 8, 2021 at 17:43

6 Answers 6

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

15
  • 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. May 25, 2018 at 15:12
  • 37
    @ZygmuntKrynicki I am astonished too. The default mount points should be configured through a config file and not enforced.
    – markhor
    Nov 22, 2019 at 9:12
  • 39
    @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. Feb 7, 2020 at 16:20
  • 8
    @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? May 4, 2020 at 7:01
  • 10
    @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. Sep 21, 2020 at 12:26
13

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>

5
  • 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, 2021 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, 2021 at 0: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, 2021 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, 2022 at 17:42
  • Awesome, at least some way to run a snap app...
    – LetynSOFT
    Oct 3, 2022 at 19:54
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

7
  • 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, 2022 at 21:15
  • 1
    To expand on @Emilio's comment, see Where in "/" should extra permanent disks be mounted?. Mar 24 at 18:33
  • 2
    Snap is super user-friendly, no doubt. May 10 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. May 25 at 7: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 at 19:14
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
  • 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. May 29, 2018 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. May 29, 2018 at 18:51
  • 6
    I do however, really appreciate your taking the time to write here, Zygmunt. Thank you. May 29, 2018 at 18:53
  • 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. Oct 20, 2019 at 21:51
  • 7
    @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, 2020 at 20:19
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.

8
  • 6
    This won't work in the common use case of a NFS-mounted multi-terabyte NAS drive. Apr 28, 2019 at 20:11
  • 2
    Copying files into some snap installation also defeats the purpose of having secure drives like Veracrypt. May 14, 2020 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, 2020 at 20:25
  • 6
    sudo snap remove --purge <app> && sudo apt install <app>
    – Matthieu
    Oct 26, 2020 at 9: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 <app> 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 7, 2020 at 16:23
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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .