This is a somewhat recent regression, I could do that a few weeks ago.

STR:

• Mount a CIFS share in GNOME's
• Right click, "Save link target as"
• Select a folder within CIFS share where you have credentials

Expected:

• File is downloaded

Actual:

• Nothing happens, and no error is reported.

from journalctl

juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_basename: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_dirname: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: Failed to register smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip: Failed to open smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip

Failed to open comes from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L91-L92 called from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/file-chooser.c#L121

From the asserts, it means that somehow path ends up nullptr: https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L79-L82

(gdb) call g_file_get_uri (file)
XDP: No background permissions found: Le d\u00e9lai d\u2019attente est d\u00e9pass\u00e9
$3 = 0x7fffe8008110 "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip"
(gdb) call g_file_get_uri_scheme (file)
$4 = 0x7fffec00d140 "smb"
(gdb) call g_file_get_path (file)
XDP: Checking background permissions
$5 = 0x0
(gdb) 

I cant repro the behavior outside of snap it seems:

#include <stdio.h>
#include <glib.h>
#include <gio/gio.h>

void
print_type (const char* file_uri)
{
        GFile* my_file = g_file_new_for_uri(file_uri);
	char* path = g_file_get_path(my_file);
	fprintf (stdout, "uri:%s => path:%s\n", file_uri, path);
        g_object_unref(my_file);
}

int
main (void)
{
        const char* files[] = {
                "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip",
        };
        int num_files = sizeof(files)/sizeof(files[0]);
        for(int f = 0; f < num_files; ++f) {
                print_type(files[f]);
        }
        return 0;
}

build with

gcc gio-test-files.c `pkg-config --cflags --libs glib-2.0 --libs gio-2.0` -o gio-test-files

and running:

$ ./gio-test-files 
uri:smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip => path:/run/user/1000/gvfs/smb-share:server=192.168.1.36,share=documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip

The same code packaged as a snap, installed in devmode returns nullptr :(

From https://forum.snapcraft.io/t/interface-suggestion-gvfs/17080/8 there's a similar situation. Indeed, there is no $SNAP/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so at all. Also, building and running outside of snap and making this libgvfsdbus.so unavailable, I can repro, so it's likely because we are missing it?

GIMP fixed it with: https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/desktop-launch/common/desktop-exports#L291-L292

I cannot find where is coming from snap/command-chain/desktop-launch on firefox' snap

Ok, it looks like desktop-launch comes from third-party dependency. This is really starting to get very snap specific, and gimp has some workaround:

• https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/snap/snapcraft.yaml#L38-L41
• https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/desktop-launch/common/desktop-exports#L291-L292

Now, if gimp already has a workaround and we need the same, maybe it's time to do what was asked in https://forum.snapcraft.io/t/interface-suggestion-gvfs/17080/8 and expose the requirements within gnome-platform directly ?

(In reply to Alexandre LISSY :gerard-majax from comment #1)

from journalctl

juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_basename: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_dirname: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: Failed to register smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip: Failed to open smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip

Can confirm, seeing this journal entry as well when trying to open an image from an SMB share:

Jun 10 18:16:01 mysys xdg-desktop-por[4507]: g_path_get_basename: assertion 'file_name != NULL' failed
Jun 10 18:16:01 mysys xdg-desktop-por[4507]: g_path_get_dirname: assertion 'file_name != NULL' failed
Jun 10 18:16:01 mysys xdg-desktop-por[4507]: Failed to register smb://192.168.1.3/share/image.jpg: Failed to open smb://192.168.1.3/share/image.jpg

(In reply to Alexandre LISSY :gerard-majax from comment #2)

Failed to open comes from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L91-L92 called from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/file-chooser.c#L121

From the asserts, it means that somehow path ends up nullptr: https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L79-L82

(gdb) call g_file_get_uri (file)
XDP: No background permissions found: Le d\u00e9lai d\u2019attente est d\u00e9pass\u00e9
$3 = 0x7fffe8008110 "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip"
(gdb) call g_file_get_uri_scheme (file)
$4 = 0x7fffec00d140 "smb"
(gdb) call g_file_get_path (file)
XDP: Checking background permissions
$5 = 0x0
(gdb) 

It looks like it is done on purpose: https://github.com/flatpak/xdg-desktop-portal/blob/fe9c5a11a199c966b32f6b7327136782544b845e/src/xdg-desktop-portal.c#L380-L381

So, while using the smb:// from file picker is blocked and seems not to be hideable for the moment, directly using the mount point should work. if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location.

This is working for me. While not optimal, at least you can make use of the remote file server.

The upstream issue tracking being able to perform that operation is https://github.com/flatpak/xdg-desktop-portal/issues/213. Until this is addressed, I believe the UI should not expose mount points it cannot handle, as reported on https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/48

(In reply to Alexandre LISSY :gerard-majax from comment #12)

So, while using the smb:// from file picker is blocked and seems not to be hideable for the moment, directly using the mount point should work. if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location.

This is working for me. While not optimal, at least you can make use of the remote file server.

Thanks for investigating further! I can confirm that this workaround works for me as well. Not sure why I didn't try that before (see next paragraph).

Unfortunately this entire issue here is yet another sad example for me of a major functionality regression on desktop Linux caused by changes behind the scenes. Going through /var/run/... is something that has not been necessary in years with Firefox packaged in APT. And seeing that this is already open for four years, I have a feeling we'll see a fix in 2030...

In any case, at least the path forward is clear now.

" if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location."

Via that path, I have no mountpoints listed in the FF picker here.

FF snap file picker shows non-functioning mountpoints on left, and none via gvfs on right.

(In reply to Al Savage from comment #16)

Created attachment 9281035 [details]
Screenshot from 2022-06-13 07-22-50.png

FF snap file picker shows non-functioning mountpoints on left, and none via gvfs on right.

Did you mount these shares e.g. via Nautilus before navigating to the gvfs subfolder? If you mount only when the file picker is already showing this folder, the file picker view is not refreshed. Either close the picker then and go to the location again or navigate one folder higher (1000) and then back into gvfs. You should then see the shares.

If still not, what does running ls -al /var/run/user/1000/gvfs in a console print out?

Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.

asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
total 0
drwx------  2 asavage asavage  40 Jun 11 00:20 .
drwx------ 21 asavage asavage 660 Jun 11 08:57 ..

I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

(In reply to Al Savage from comment #15)

" if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location."

Via that path, I have no mountpoints listed in the FF picker here.

This is not "Firefox picker", it's the portal one. And if your mountpoints are not visible there, this is another issue, unrelated to Firefox itself.

(In reply to Al Savage from comment #18)

Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.

asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
total 0
drwx------  2 asavage asavage  40 Jun 11 00:20 .
drwx------ 21 asavage asavage 660 Jun 11 08:57 ..

I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

Then your user probably has a different user ID than 1000 (run echo $UID or id in a terminal and adjust your folder accordingly). I agree with comment #19 though that this is an unrelated issue.

Just to be clear, when I'm using FF, and choose RMB "Save Image as", that's FF's File Picker. You can call it whatever you like, but from a user perspective, you can't argue it's called something else. I'm a user, not a developer, and I won't cater to your nomenclature whims. If you have misunderstood what I was relating, my apology in advance. I have made considerable effort in both documenting this issue weeks ago, and posting links to the bug in other fora, in an attempt to drive others with the issue to the bug, which you then marked as duplicate because you couldn't bother to search for the existing bug, and decided that your 'discovery' of it was the proper bug-chasing path, instead of marking your newer bug report as a duplicate of the older. I do not appreciate your choice, but because you are actually reading and chasing the issue, I let it be.

You can see in the screenshot fragment above that the shares are shown as mounted in the left pane, in the FF file picker.

asavage@Ubuntu1:~$ echo $UID
1000
asavage@Ubuntu1:~$ id
uid=1000(asavage) gid=1000(asavage) groups=1000(asavage),4(adm),7(lp),24(cdrom),27(sudo),29(audio),30(dip),44(video),46(plugdev),110(lxd),114(sambashare),119(lpadmin),128(pulse),129(pulse-access)

Again, Nautilus allows use of these mounted shares without issue.

(In reply to Al Savage from comment #21)

Just to be clear, when I'm using FF, and choose RMB "Save Image as", that's FF's File Picker. You can call it whatever you like, but from a user perspective, you can't argue it's called something else. I'm a user, not a developer, and I won't cater to your nomenclature whims. If you have misunderstood what I was relating, my apology in advance.

It is not "nomenclature whims", there's a very simple problem if it's not our code: we can't fix it, and we depend on upstream to fix and deploy. Even if I could fix the issue myself (which from the discussion I had with people of upstream is non trivial).

I have made considerable effort in both documenting this issue weeks ago, and posting links to the bug in other fora, in an attempt to drive others with the issue to the bug, which you then marked as duplicate because you couldn't bother to search for the existing bug, and decided that your 'discovery' of it was the proper bug-chasing path, instead of marking your newer bug report as a duplicate of the older. I do not appreciate your choice, but because you are actually reading and chasing the issue, I let it be.

Who said your investigation was useless? I found 4 differents dupes after, because the issue is hitting many people and they were filed differently enough. There's no judgement whatsoever when marking as dupe, I just found it after and I was already working on it.

You can see in the screenshot fragment above that the shares are shown as mounted in the left pane, in the FF file picker.

asavage@Ubuntu1:~$ echo $UID
1000
asavage@Ubuntu1:~$ id
uid=1000(asavage) gid=1000(asavage) groups=1000(asavage),4(adm),7(lp),24(cdrom),27(sudo),29(audio),30(dip),44(video),46(plugdev),110(lxd),114(sambashare),119(lpadmin),128(pulse),129(pulse-access)

Again, Nautilus allows use of these mounted shares without issue.

Again, there's no code we have direct control over in this file picker. We ask GTK to show one, and GTK under Snap does the job. We dont control anything.

(In reply to Al Savage from comment #18)

Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.

asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
total 0
drwx------  2 asavage asavage  40 Jun 11 00:20 .
drwx------ 21 asavage asavage 660 Jun 11 08:57 ..

I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

So you have nothing in that folder, I dont know why, but it's consistent with the folder being empty within the file picker.

Could you check if you have gvfs-fuse installed? That's the component in charge of creating the local mountpoints

There's a draft PR to fix it

(In reply to Alexandre LISSY :gerard-majax from comment #25)

There's a draft PR to fix it

I had one weird hiccup, but I cant reproduce anymore, looks like this PR is working and fixing our issue.

If I understand the latest developments on this bug correctly, this has to be fixed in the XDG desktop portal, and Sergio's PR is an attempt to do that.

There's also an issue in Firefox where it should be calling SaveFiles instead of SaveFile. Or is that fixed already?

(In reply to Olivier Tilloy from comment #27)

If I understand the latest developments on this bug correctly, this has to be fixed in the XDG desktop portal, and Sergio's PR is an attempt to do that.

It seems, I dont know when we can expect this to hit your distro.

There's also an issue in Firefox where it should be calling SaveFiles instead of SaveFile. Or is that fixed already?

This is a separate problem.

Marking this one as P5 because the fix needs to happen in Snap (where there is a proposed patch).

Sergio, do you need me to test the new PR ?

I already tested it and seems to work. Anyway, I'm not sure if they will accept it, so I think that Firefox should also check the received list of URIs and, if it's empty (because the user tried to save into a remote folder), show a more specific error.

Something like "Destination not supported due to security constraints" or something like that.

(In reply to Sergio Costas from comment #31)

I already tested it and seems to work. Anyway, I'm not sure if they will accept it, so I think that Firefox should also check the received list of URIs and, if it's empty (because the user tried to save into a remote folder), show a more specific error.

Except this is all going through GTK and we dont have such information.

Yes, you are right...

Sergio, I understand you're also waiting, but what can we do to move forward your new PR ? There's no activity so far on it.

Sorry for the delay. We are ATM working on trying to find a solution for that review.

What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?

In which case will it also block saving in locations like '/tmp/' that are not exposed to the Snap host ?

(In reply to tc from comment #37)

What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?

Still blocked on upstream ...

I discovered a simpler way of fixing this. I sent this patch for XDG-desktop-portal-gnome. https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67

(In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-28/02/2023] from comment #38)

(In reply to tc from comment #37)

What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?

Still blocked on upstream ...

Have you tested the new patch?

(In reply to Sergio Costas from comment #40)

(In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-28/02/2023] from comment #38)

(In reply to tc from comment #37)

What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?

Still blocked on upstream ...

Have you tested the new patch?

Sorry, I was on leave, is testing the patch still required ?

Have you tested the new patch?

Sorry, I was on leave, is testing the patch still required ?

It would be great if you can test it. In fact, I've been working on it yesterday and today, doing some changes requested by Bastien.

(In reply to Sergio Costas from comment #42)

Have you tested the new patch?

Sorry, I was on leave, is testing the patch still required ?

It would be great if you can test it. In fact, I've been working on it yesterday and today, doing some changes requested by Bastien.

I'm going to give it a try then.

Sergio, I applied the patch locally on xdg-desktop-portal-gnome package, and it is fixing the issue.

(In reply to Alexandre LISSY :gerard-majax from comment #44)

Sergio, I applied the patch locally on xdg-desktop-portal-gnome package, and it is fixing the issue.

Thanks!

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gerard-majax, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Last activity was three weeks ago, how are we looking wrt a fix?

The patch is sent, but it seems that there were some changes in the maintainers of xdg-desktop-portal-gnome, so I suspect that it will need some time until it is merged upstream... :-(