I have a automounted filesystem setup in /etc/fstab and is mounted under /mnt/mountpoint_name, VLC snap fails to read media files in such location.
fstab entry:
/dev/disk/by-uuid/<uuid> /mnt/mountpoint_name auto suid,dev,nofail,x-gvfs-show,x-systemd.device-timeout=1 0 2
AFAICT currently snap only provides interface to removable medias and doesn’t support this configuration.
UPDATE: The log
filesystem error: cannot open file /mnt/mountpoint_name/somepath/some_file.mkv (No such file or directory)
you can mount your filesystem under /media instead to make ths work though …
The /mnt directory and anything mounted there is not supported yet (as @ogra said, you can try /media which will work and has appropriate interfaces already) but given that /mnt is even older I wonder if we should support /mnt.
CC @jdstrand for opinions, I can make things happen once we have an agreement.
I’m not opposed to creating rules for /mnt, perhaps in another ‘removable-media’-like interface. The mountpoints in /mnt are not well-formed or regular though, so the rules would be:
# Description: Can access temporary mounted filesystems in /mnt
/mnt/ r,
/mnt/** rwk,
Note, the description for this comes from http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATEMPORARILYMOUNT and arguably the requester of this feature is misusing this location since the fstab entry looks like a permanent location. Of course, /mnt is there and users aren’t obliged to adhere to the FHS…
Perhaps the /mnt rules simply belong in removable-media? The mountpoints aren’t necessarily ‘media’ but since /mnt is typically (according to FHS) for ‘temporary mounts’, ‘removable’ does seem to fit.
The question then becomes, where does this stop? Eg, what about /srv? While /srv is supposed to be for data files the system serves (eg, ftp, http, etc), I’ve seen people use /srv as an alternative to /mnt (eg, especially in relation to a backup server and NFS).
@niemeyer - thoughts? It is pretty clear to me we should continue to ignore /srv. Based on the FHS description, I think I am leaning towards adding /mnt to the removable-media interface, but could easily be swayed to a separate mnt- interface.
I’ve implemented the interface and will post it shortly. I would welcome contributions on the documentation page once it is ready: Interface:mnt
EDIT: The interface was tentatively renamed to just mnt
/media mounts couldn’t be seen either by some apps, like Discord. Visual Studio Code works fine, however.
This is unrelated to /mnt but let me just say that it depends on the snap using the removable-media interface plug and said plug being actually connected.
I’m leaning towards adding this to removable-media as well, as suggested by @jdstrand above. This directory was the typical place for removable media before /media showed up, and in both cases the sort of content we can have mounted under them is undefined and inconsistent in terms of structure. So forcing users to think about the two independently just feels like a nuisance.
You’re right. The main concern of this topic is for big internal hard drives specifically for storing data (like users’ photos and videos and ***n), as it is internal it didn’t fall into the removable-media category and it isn’t temporary mounted as well. According to F.H.S. it probably should mount to a random user-defined location like /data but this configuration will never(?) be supported by snapd.
The trouble is that we might always be running into this kind of problems. IMHO there should be a kind-of “superhome” interface that allows a snap to perform any file access the user is allowed to.
I think I just asked something like this few minutes ago. That’s what you meant right?