[snap] Files on local network shares are not opened / written

Bug #1971168 reported by Markus W
84
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Unknown
firefox (Ubuntu)
Triaged
High
Unassigned
xdg-desktop-portal (Ubuntu)
Triaged
High
Unassigned
xdg-desktop-portal-gnome (Ubuntu)
Fix Released
Undecided
Sergio Costas
Jammy
Fix Released
Undecided
Sergio Costas
Lunar
Won't Fix
Undecided
Unassigned

Bug Description

[ Impact ]

When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop-portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails.

The previous backend, xdg-desktop-portal-gtk, did work fine in these cases because it returned the local path that corresponded to the remote file when exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression.

The old behavior has now been "set on stone" in the XDG portal specification, mandating that the backends must always return local paths, no matter if the chosen file is a local or remote one, by using FUSE.

[ Test plan]
Steps to reproduce:

1. Run Firefox as a Snap package in Ubuntu 22.04
2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`)
3. Have one such share mounted and writable
4. Open any website containing images in Firefox
5. Right-click on an image and select "Save Image As..."
6. In the file save dialog, navigate to the mounted share
7. Assert content of network share is visible and browsable from within the save dialog
8. Select "Save" at any folder in the network share

Actual behavior:

* File is not saved to selected network share location
* No download entry is created
* No error is shown

Expected behavior:

* File is saved to selected network share location
* No error is shown

[ Where problems could occur ]

- If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now.

- Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch.

[ Additional information ]

* When saving to a folder on the local machine instead, saving works correctly as expected
* In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share
* Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine.

Markus W (z-mw)
description: updated
Changed in firefox (Ubuntu):
status: New → Invalid
Revision history for this message
In , Markus W (z-mw) wrote :

Steps to reproduce:

1. Run Firefox (version 99.0 or 100.0b9) as a Snap package in Ubuntu 22.04 (upgraded from 21.10)
2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`)
3. Have one such share mounted and writable
4. Open any website containing images in Firefox
5. Right-click on an image and select "Save Image As..."
6. In the file save dialog, navigate to the mounted share
7. Assert content of network share is visible and browsable from within the save dialog
8. Select "Save" at any folder in the network share

Actual results:

* File is not saved to selected network share location
* No file download entry is created in "Downloads"
* No error is shown

Expected results:

* File is saved to selected network share location
* No error is shown

Additional information:

* When saving to a folder on the local machine instead, saving works correctly as expected
* In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share

Revision history for this message
In , Markus W (z-mw) wrote :
Download full text (3.5 KiB)

Output of `journalctl -f | grep DEN` when trying to save to the network share is as follows:

```
Mai 04 11:30:18 athlon audit[5959]: AVC apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/run/mount/utab" pid=5959 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mai 04 11:30:18 athlon kernel: audit: type=1400 audit(1651656618.225:90): apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/run/mount/utab" pid=5959 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:91): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:93): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:95): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kerne...

Read more...

Revision history for this message
In , Markus W (z-mw) wrote :

For debugging purposes I added and activated the following changes for the Firefox apparmor profile:
```
/run/mount/utab r,
/etc/fstab r,
dbus (send)
    bus=system
    path=/org/freedesktop/hostname1
    interface=org.freedesktop.DBus.Properties
    member=GetAll
    peer=(label=unconfined),
```
Now the apparmor deny messages no longer appear in the journal but saving files to the network share still does not do anything as before.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

Thanks for the report Markus. In contrast to saving, does opening files from a network share work within firefox?

Revision history for this message
In , Markus W (z-mw) wrote :

Just checked, that's not working either.

To test, I open a new tab, press Ctrl + O to get the "Open File" dialog, browse to the network share and double-click e.g. a .png file. The file dialog then closes and nothing else happens. The image is not opened.

If I do the same steps with an image on the local drive, it opens fine.

In summary, the only thing that works on the network share is creating a new folder from within the "Save" file dialog.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

I've set up a samba share on my machine and I can confirm the problem. The share can be browsed, but files on it aren't opened, and there's no user feedback.

6 comments hidden view all 110 comments
Revision history for this message
Erich Eickmeyer (eeickmeyer) wrote :

Thank you for taking the time to report this bug and help make Ubuntu better. Firefox is provided by a snap published by Mozilla, and they may not be aware of this issue. Please contact them via https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla and link the bug report here so it can be further tracked. Thank you!

Changed in firefox (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
Markus W (z-mw) wrote :

Corresponding bug in Mozilla bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1767316

Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: Incomplete → Confirmed
Changed in firefox:
status: Unknown → Confirmed
6 comments hidden view all 110 comments
Revision history for this message
In , Al Savage (asavage-d) wrote :

I just upgraded Ubuntu from 21.10 to 22.04, and now Chrome (deb), Thunderbird (snap), and FireFox (snap) will not open nor save to any network drives (a home Ubuntu server); all of these apps read/saved to the same server before the upgrade this afternoon. So, "me too", but also it may not be limited to FF, snaps, or even Mozilla, since my Chrome install behaves similarly.

1 comments hidden view all 110 comments
Revision history for this message
In , Markus W (z-mw) wrote :

(In reply to Al Savage from comment #6)
> [...] it may not be limited to FF, snaps, or even Mozilla, since my Chrome install behaves similarly.

You are right, this is actually affecting other applications, too. I get the exact same behavior described in the steps to reproduce when using Chromium installed via snap: Local files open fine, opening files on network shares does not trigger any reaction.

Should this issue here remain open?

Revision history for this message
Markus W (z-mw) wrote :

I've updated the bug to reflect that multiple applications are affected by this. On my system I can reproduce the issue with Firefox and Chromium, both installed via snap.

description: updated
summary: - [snap] Downloaded files not saved when saving to local network share
+ [snap] Files on local network shares are not opened / written
1 comments hidden view all 110 comments
Revision history for this message
In , Al Savage (asavage-d) wrote :

Created attachment 9275732
Screenshot of Firefox's File|Open dialogue, showing missing remote locations

[snap] Firefox's File|Open dialogue shows missing information in the Location column for Recent files that are non-local.

[.deb] Chrome shows exactly the same behaviour on this workstation.

(I also filed bug 1768492 for the File|Open dialogue resizing 244px larger every time you open it, until it fills the viewport.)

Revision history for this message
In , Al Savage (asavage-d) wrote :

Created attachment 9276133
File pickers comparison 1

I've spun up a fresh 22.04 install in a VM, then run the snap version of ff 100 (on the right) and ff 100 from linux binaries (on the left). The file picker is different between the two versions; the binaries version shows fewer network share aliases, and this binaries version can successfully read and write to network shares.

The snap version's file picker shows aliases for network shares (and a printer) and will navigate into those folders and show files, but when a file is chosen to open, ff does not read the file and does not display an error.

Revision history for this message
In , Al Savage (asavage-d) wrote :

Created attachment 9276134
File pickers comparison 2

In "File pickers comparison 2", I show that the two file pickers (ff run from linux binaries vs the snap package) sort files in a different order, have different options at the bottom, and the bottom window corners are either square or rounded.

The snap's file picker resizes poorly here, as well.

I ran the ff linux binaries version using the suggestion from https://bugzilla.mozilla.org/show_bug.cgi?id=1768500#c5

Revision history for this message
In , Al Savage (asavage-d) wrote :

In the fresh VM, I just installed Chrome (google-chrome) from binaries, and it too uses the troublesome file picker, and has the same issues ("sees" network shares files but does not read them; resizes poorly; window enlarges by 244px both H & V every time it's invoked).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu):
status: New → Confirmed
1 comments hidden view all 110 comments
Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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.

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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
```

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

`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)
```

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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
```

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

Created attachment 9280651
gio.zip

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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?

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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 ?

Revision history for this message
In , Markus W (z-mw) wrote :

(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
```

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

*** Bug 1767316 has been marked as a duplicate of this bug. ***

10 comments hidden view all 110 comments
Revision history for this message
Markus W (z-mw) wrote :

New bug ticket was opened where investigation is continued.

Changed in firefox:
status: Confirmed → Unknown
11 comments hidden view all 110 comments
Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

(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

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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.

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

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

Revision history for this message
In , Markus W (z-mw) wrote :

(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](https://github.com/flatpak/xdg-desktop-portal/issues/213) 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.

Revision history for this message
In , Al Savage (asavage-d) wrote :

" 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.

Revision history for this message
In , Al Savage (asavage-d) wrote :

Created attachment 9281035
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.

Revision history for this message
In , Markus W (z-mw) wrote :

(In reply to Al Savage from comment #16)
> Created attachment 9281035
> 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?

Revision history for this message
In , Al Savage (asavage-d) wrote :

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.

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

(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.

Revision history for this message
In , Markus W (z-mw) wrote :

(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](https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c19) though that this is an unrelated issue.

Revision history for this message
In , Al Savage (asavage-d) wrote :

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.

Changed in firefox (Ubuntu):
importance: Undecided → High
Changed in firefox (Ubuntu):
status: Confirmed → Triaged
affects: snapd (Ubuntu) → xdg-desktop-portal (Ubuntu)
Changed in xdg-desktop-portal (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → Confirmed
Changed in xdg-desktop-portal-gnome (Ubuntu):
status: New → In Progress
assignee: nobody → Sergio Costas (rastersoft-gmail)
Jeremy Bícha (jbicha)
no longer affects: xdg-desktop-portal (Ubuntu Jammy)
no longer affects: xdg-desktop-portal (Ubuntu Lunar)
no longer affects: firefox (Ubuntu Jammy)
no longer affects: firefox (Ubuntu Lunar)
Changed in xdg-desktop-portal-gnome (Ubuntu Jammy):
status: New → Triaged
Changed in xdg-desktop-portal-gnome (Ubuntu Lunar):
status: New → Triaged
Changed in xdg-desktop-portal-gnome (Ubuntu):
status: In Progress → Fix Committed
description: updated
description: updated
Changed in xdg-desktop-portal-gnome (Ubuntu):
status: Fix Committed → Fix Released
30 comments hidden view all 110 comments
Revision history for this message
Miguel (xadrezmiguelpires) wrote :

The fix is for 22.04?
If yes something is wrong because i cant upload files from remote folders

Revision history for this message
Oliver Grawert (ogra) wrote :

It is fixed in the development release and will still need to hit 22.04 via https://wiki.ubuntu.com/StableReleaseUpdates ... (as you can see at the top, the jammy and lunar tasks are still open)

1 comments hidden view all 110 comments
Revision history for this message
Bas van den Heuvel (2-bas) wrote :

For those who are interested. I modified the patch from Sergio Costas Rodriguez to version 42.1 which is shipped with Ubuntu 22.04

It works on my laptop :-)

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "filechooser_42.1_patch.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

Sergio is still actively working on landing this on upstream

Revision history for this message
In , Sergio Costas (rastersoft-gmail) wrote :

That's right. I'm working on landing this on upstream. As commented, the problem is in xdg-desktop-portal-gnome.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

The patch for xdg-desktop-portal-gnome is continuing its way towards being mainlined: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

The patch has been merged, and also has been backported to GNOME 45, so it is possible that it can make it to Mantic.

Revision history for this message
In , Sergio Costas (rastersoft-gmail) wrote :

The patch has landed in upstream today.

Revision history for this message
In , Sergio Costas (rastersoft-gmail) wrote :

(In reply to Sergio Costas from comment #52)
> The patch has landed in upstream today.

I mean: it has been merged today.

Jeremy Bícha (jbicha)
description: updated
Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Hi,
This bug going to be solved for 22.04?

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

Yes, it should, because the patch has been merged in upstream.

Revision history for this message
Miguel (xadrezmiguelpires) wrote :

It don't work, you can select a file but it don´t upload

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

I have to check it, but probably the reason is that it still is using the current version of gnome shell, so it won't be fixed until Gnome 46 is added to the repositories.

Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Soo no fix to 22.04?

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote (last edit ):

Oh, you mean if it will be backported to LTS! I'm not sure... I'll check it.

(sorry, I read the numbers wrong and interpreted 24.04)

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

Ok, I think that the problem is that the bug report is in "firefox" instead of "xdg-desktop-portal-gnome". I'll prepare a new bug report there with the patch from Bas van den Heuvel. Sorry for the mistake.

Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Ok Thks for all the work

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

Thanks! What is the status, can we considered this as fixed? assuming we have to wait for backports?

Revision history for this message
In , Sergio Costas (rastersoft-gmail) wrote :

Yes, this can be considered as fixed. It was merged in upstream (gnome 46), and also backported to Gnome 45.

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

Thanks, do you know what ubuntu release currently has that out of `-proposed` ?

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

(In reply to :gerard-majax from comment #56)
> Thanks, do you know what ubuntu release currently has that out of `-proposed` ?

Tested on 22.04 it's not yet backported, but it looks to be working on uptodate 23.10.

Revision history for this message
In , Sergio Costas (rastersoft-gmail) wrote :

For 23.10, as soon as version 45.1 enters, it will be fixed. For 22.04 I prepared a SRU, but since it's a LTS version, it's a slow process.

Changed in firefox:
status: Confirmed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote :

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.

Changed in xdg-desktop-portal-gnome (Ubuntu Lunar):
status: Triaged → Won't Fix
Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Sergio any news about this?

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :
Changed in xdg-desktop-portal-gnome (Ubuntu Jammy):
assignee: nobody → Sergio Costas (rastersoft-gmail)
status: Triaged → Fix Committed
description: updated
description: updated
Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Sergio any news about this?

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

None yet, sorry.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

Good news: the patch has been merged in Salsa server.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

the changelog entry doesn't match the contents, but meh

tags: added: verification-needed verification-needed-jammy
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

Hello Markus, or anyone else affected,

Accepted xdg-desktop-portal-gnome into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xdg-desktop-portal-gnome/42.1-0ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

Thanks!

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

@xandrezmiguelpires Can you test it too, please?

Revision history for this message
Markus W (z-mw) wrote :

Re #103
Just tested the new package from proposed together with Firefox 127.0.2. Things appear to work just as expected now and I can no longer reproduce the issue. Haven't found any side-effects in other places either so far.

Looks like this is now finally fixed in 22.04 with only a few weeks left before the upgrade to 24.04 rolls out ;)

Revision history for this message
Miguel (xadrezmiguelpires) wrote :

Re #105

I can confirm, like Markus write, everything are working for now as expected.

I will continue testing and report later

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks, marking as verified accordingly

tags: added: verification-done verification-done-jammy
removed: verification-needed verification-needed-jammy
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xdg-desktop-portal-gnome - 42.1-0ubuntu2

---------------
xdg-desktop-portal-gnome (42.1-0ubuntu2) jammy; urgency=medium

  * New upstream bugfix release (LP: #1971168)

 -- Sergio Costas Rodriguez <email address hidden> Tue, 21 Nov 2023 20:22:47 +0100

Changed in xdg-desktop-portal-gnome (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for xdg-desktop-portal-gnome has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Displaying first 40 and last 40 comments. View all 110 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.