Difficulty viewing mounted fileystems via samba / nfs / gvfs interface

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.

  1. Have a remote samba share on your network containing an image
  2. 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.
  3. Install GIMP snap and launch it
  4. File -> Open in GIMP.
  5. Note that the previously mounted folder doesn’t show up in the side bar
  6. Note that /run can’t be navigated to in the file open dialog (although /run/user/$UID/gvfs is 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.

I also tested this and encountered similar problems - also valid for KDE/Qt apps.

On Kubuntu 18.04, I tried with Okular.

  • Non-snap (deb from archive) shows all network paths correctly, including Samba bookmarks and Google Drive, for instance.
  • Snap shows a network location only (no other shortcuts, bookmarks), but clicking on it does nothing.

Not sure if this is a snapd or desktop-helper related thing. @jdstrand @jamesh - suggestions for debugging welcome!

Are there any denials when doing this?

Yup.

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:

Whereas in the file manager I see way more possibilities:

(click the images, they’re bigger than the forum preview shows)

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.

When you say “focus on portals”, what does that mean from the perspective of someone who is packaging up a snap? (i.e. me).

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:

  1. Ensure the portals service is installed on the host system by running apt install xdg-desktop-portal xdg-desktop-portal-gtk
  2. Run your application with GTK_USE_PORTAL=1 set in the environment.
  3. 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:

https://gitlab.gnome.org/GNOME/gedit/merge_requests/2/diffs

If you’re lucky, someone will already have done this work to make the app portal-friendly for a Flatpak release.

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.

Any other ideas?

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:

  1. rip out the code that tries to dlopen libgtk-3.so.0, and update CMakeLists.txt to actually link with GTK.
  2. Replace the gtk_file_chooser_dialog_new call with a gtk_file_chooser_native_new call.
  3. 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