I’ve had a few users and developers report that they can’t use snapped applications because their data is held on a remote server, and the client cannot see the files. This is typically because the user has manually mounted the remote directory using their file manager.
Steps to reproduce, on Ubuntu 19.10.
Have a remote samba share on your network containing an image
Using the file manager, navigate to the samba share such that you now have a filesystem mounted in /run/user/$UID/gvfs. Observe that the mounted folder shows up in the side bar in the file manager.
Install GIMP snap and launch it
File -> Open in GIMP.
Note that the previously mounted folder doesn’t show up in the side bar
Note that /run can’t be navigated to in the file open dialog (although /run/user/$UID/gvfsis browseable, and files can be opened).
What methods can we use to expose the mounted nfs / samba filesystems to the snap. Using removable-media isn’t sufficient.
My actual issue is with a snap I published called OpenBoardView, but in my steps above I used GIMP simply because it exhibits the same issue, and is familiar.
When I open the File -> Open dialog it says this:
= AppArmor =
Time: Dec 17 11:22:28
Log: apparmor="DENIED" operation="open" profile="snap.openboardview.openboardview" name="/run/mount/utab" pid=5705 comm="openboardview" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /run/mount/utab (read)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use /run/shm/snap.$SNAP_NAME.*
* adjust program to use /run/snap.$SNAP_NAME.*
* adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
The file dialog looks like this in the application:
I don’t think there is a good solution to get the GVFS bookmarks to display for a file chooser running within confinement: I don’t think exposing gvfsd’s D-Bus interface would be a good idea, and it’s not clear that would even be sufficient. It’s probably better to focus on portals, since this should give identical bookmarks to everything else on the host system.
Apps should still be able to read $XDG_RUNTIME_DIR/gvfs paths if they plug the home interface, but that doesn’t imply being able to navigate all the paths above it.
What I mean is that it will likely be easier to get portals working correctly everywhere than trying to get the bookmarks working without portals.
As a snap developer, you can test how your snap runs with portals as follows:
Ensure the portals service is installed on the host system by running apt install xdg-desktop-portal xdg-desktop-portal-gtk
Run your application with GTK_USE_PORTAL=1 set in the environment.
Attempt to open or save a file.
Note that use of the portal-based file chooser is dependent on the application making use of the GtkFileChooserNative API to present it’s file choosers. If it is using the older GtkFileChooserDialog API, then it will require code changes. The difficulty of the code changes will largely depend on how much the app customised the file chooser. A while back I ported gedit over to the new API, which turned out to be of intermediate difficulty due to the use of additional widgets and custom filters:
Sadly setting that environment variable didn’t help. The application (openboardview) appears to be using a 3rd party library for the GUI controls and menus, called imgui. I don’t believe it’s using new GtkFileChooserDialog API.
It looks like the file chooser code is part of OpenBoardView itself rather than imgui:
Complicating matters, it looks like it is trying to load either GTK 2 or GTK 3 at runtime via dlopen and then run the same code. It’s kind of surprising that they got that to work at all, and it looks like it is leaking at least a GtkWindow each time the dialog is presented.
Updating it would probably involve:
rip out the code that tries to dlopen libgtk-3.so.0, and update CMakeLists.txt to actually link with GTK.
Replace the gtk_file_chooser_dialog_new call with a gtk_file_chooser_native_new call.
Replace the gtk_dialog_run call with a gtk_native_dialog_run call.
There’s probably a few type changes and cast changes needed in addition to this, but that’s about it. It doesn’t look like it is using any particularly complex file chooser features, but it wouldn’t be possible to maintain GTK 2 compatibility with this change.
I don’t know how acceptable these changes would be to upstream though: I’ve got no idea why they thought dlopening GTK was a good idea in the first place.
I have the same problem with my proposed App.
When calling the JavaFX DirectoryChooser and FileChooser methods, access to SMB network shares and USB files systems is only permitted through the top level /media directory,which for the non expert Linux user is hardly an acceptable User experience - my app is targeted at photographers!
It would appear that the Chromium snap has worked successfully around this issue and has presented a directory chooser that has links to network storage and USB connected file systems.
Has anyone documented a solution?
cheers
Alan
they work fine if your snap uses portals instead of native dialogs … but as you can see above this isnt always that case if apps implement their own native file choosers etc… so it is a matter of upstreams and nothing that can easily be fixed on the snap level …
Si if we’re speaking of GiMP, it’s the dev’ team of GiMP who should « implement » portal, this can’t be done « only » by the team ( or person ) who builds the snap for GiMP, that’s it ?
I tried to upload pictures with Firefox to SmugMug from a network share mounted under a custom path via fstab, and that didn’t work. Firefox seems to have been changed to a snap on upgrade to 21.10, so I had to reinstall the deb to proceed. Flatpak also allowed me to upload but had other issues finalizing it.
