After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784490 - file open save dialog can't navigate to smb shares
file open save dialog can't navigate to smb shares
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-07-03 21:48 UTC by Chris Murphy
Modified: 2017-07-05 13:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chris Murphy 2017-07-03 21:48:52 UTC
gtk3-3.22.16-1.fc26.x86_64
gnome-shell-3.24.2-1.fc26.x86_64
Example apps: Firefox, GEdit, LibreOffice, GIMP.


Problem: Application save/open dialogs do not show connect SMB shares. And I can't navigate to find them through alternate path.


Steps to reproduce:
1. Two systems: One is Fedora 26 Server running samba, and one is Fedora 26 Workstation.
2. Click on Files > + Other Locations > enter Connect to Server info, Connect and authenticate to mount a Samba share.
3. In any application, go to File > Open or File > Save. The share is not to be found. Click on + Other Location and the shares are not listed, only locally attached storage is listed.




Expired duplicates:
https://bugzilla.gnome.org/show_bug.cgi?id=456324
https://bugzilla.gnome.org/show_bug.cgi?id=561494
Comment 1 Chris Murphy 2017-07-03 21:53:03 UTC
Workaround. From Nautilus, drag a file on the share to Terminal:

[chris@f26h ~]$ '/run/user/1000/gvfs/smb-share:server=192.168.1.115,share=scratch/wl_apsta.o' 

I can navigate to this path, and open/save files. But that's pretty screwy.
Comment 2 Daniel Boles 2017-07-03 21:55:11 UTC
What about if you type smb://the-server/the-share into the location bar?
Comment 3 Chris Murphy 2017-07-03 22:09:12 UTC
What location bar? There's a Cancel button, then a Name field. The Name field doesn't accept smb://the-server...
Comment 4 Daniel Boles 2017-07-03 22:12:36 UTC
You press Ctrl+L to show it in Open mode, but the mention of the Name field indicates you were in Save mode, where the Name field IS the location bar. I didn't really expect that to work if everything else didn't, but I had to ask for the same of completeness.
Comment 5 Chris Murphy 2017-07-03 22:29:41 UTC
OK so I'm seeing mixed results. Part of the confusion is gedit and libreoffice are flatpaks so lets ignore that for now.

After installing conventional Fedora repo gedit I see the connected share in both open and save dialogs. I do see it now in GIMP, it's just its dialogs look different, and list things differently so I didn't see it.

But not in Firefox or Chrome Save As dialogs.
Comment 6 Chris Murphy 2017-07-03 22:42:10 UTC
Oh boy let me restate that pile of confusion: non-flatpak gedit, and GIMP, I see the smb share in both open and save dialogs, as I'd expect, i.e. it's working.

But Firefox and Chrome, neither open nor save as dialogs show the share (and they aren't flatpaks). And so far any flatpak applications' dialogs also do not show the shares.
Comment 7 Daniel Boles 2017-07-03 23:01:11 UTC
(In reply to Chris Murphy from comment #5)
> OK so I'm seeing mixed results. Part of the confusion is gedit and
> libreoffice are flatpaks so lets ignore that for now.

I'm not very clued up about Flatpak, but I think that's expected, at least by default; I don't know if it can be overridden.


> I do see it now in GIMP, it's just its dialogs
> look different, and list things differently so I didn't see it.

If you're running released GIMP, it's probably because it'll be using GTK+2 and possibly a customised extension of GtkFileChooser.


> But not in Firefox or Chrome Save As dialogs.

These don't use stock GTK+ file choosers (or any other GTK+ widgets not covered by heavy layers of abstraction), so you should probably look on their side for fixes. For instance, there's this Ubuntu Launchpad bug against Firefox:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1579543

A simplified version of the workaround you found is discussed there too.
Comment 8 Daniel Boles 2017-07-03 23:09:02 UTC
Specifically, it might be as simple as the affected packages just needing to set the :local-only property of the FileChooser to TRUE before they show it:

https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-local-only

It's not clear from that Launchpad ticket whether anyone bothered trying the radical step of reporting this upstream with Firefox. If you don't have any luck finding a ticket for that or Chrome, it would be worth creating one. I can't imagine it would take them long to fix it, if it's as simple as the above... but maybe I'm wrong, if they've been told but have ignored it.

In fact, I take it back: I found the Firefox one with a simple search:

https://bugzilla.mozilla.org/show_bug.cgi?id=1187870

Chrome is left as an exercise for the reader. :P
Comment 9 Chris Murphy 2017-07-03 23:17:30 UTC
Indeed. 10 years old bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=378425
Comment 10 Daniel Boles 2017-07-03 23:23:01 UTC
You added a comment to one of the FF bugs indicating that there was advice for them here, but we can also find there that simply setting :local-only = FALSE was already suggested and does not suffice. They also have to make non-local files returned by the FileChooser usable, by adding support for the relevant backends needed to get at them. That and how to do it appear to be the sticking point, throughout the years.
Comment 11 Matthias Clasen 2017-07-05 13:55:01 UTC
I don't know why you would set local-only to TRUE. that won't fix anything. The flatpaks need to use the filechooser portal, or rather, GtkFileChooserNative in gtk. Then you will get a host-side filechooser with all the mounts you desire.