Can't load/save files from Samba gvfs mount

[canonex]

Describe the bug

Ambiguous behavior using Pdf arranger flatpak with Samba.

The scenario is the need, in an office or home with a Nas where there are Samba network shares, to edit Pdfs directly from the share without having to copy them locally.
On Gnome (Debian 12 Bookworm) the shares are correctly mounted with gio mount (see attached image) and all file operations can be correctly performed using Nautilus.

To Reproduce

Steps to reproduce the behavior option A:

1. Open Pdf arranger and Nautilus on the mounted drive
2. Drag a pdf file from Nautilus and drop onto Pdf arranger
3. See error [Errno 2] Non existent file or directory '/run/user/1000/gvfs/smb-share:server=192.168.XXX.XXX,share=myjob/whatever.pdf'

Steps to reproduce the behavior option B:

1. Open Pdf arranger
2. Click on "Open", browse to the shared folder (both using the drive icon on the left of goint to the share /run/user/1000/gvfs/smb...)
3. Nothing happens: no error is displayed, no file is opened

Steps to reproduce the behavior option C:

1. Open Nautilus
2. Browse to the shared folder (both using the drive icon on the left of goint to the share /run/user/1000/gvfs/smb...)
3. Right click and select "Open with..." and select PDF arranger
4. The file is correctly opened but *** you cannot save on the remote folder, if you try nothing happens: no error is displayed, no file is saved.

Expected behavior

The ability to properly use Pdf arranger on gio mount shares or a clear message indicating that remote files are not supported.

Screenshots

System and Versions

• PDF Arranger version 1.9.2, flatpak
• Debian 12 Bookworm

Please not that that the bug is not present installing the Debian version, it seems to me it is just a flatpak issue.

Thanks a lot, it's really a cool software :)
Riccardo

[dreua]

Can you try using flatseal to allow access to those directories?

[dreua]

OK that probably won't help since we already have - --filesystem=host.

[canonex]

Adding in "others files" those paths (as ex. in Inkscape):

• xdg-run/gvfs
• xdg-run/gvfsd

it helps and enable drag and drop from samba path.
Adding:

• /run/user/1000/gvfs

it does nothing (at least for what I have tested).

But saving is still impossible (yes, I have all the write and read permissions on the remote folder :) ) and no warning.

Thank you,
Riccardo

[dreua]

I can reproduce it, just found the details here: https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access

Note that we need gvfs instead of gvfsd which would be recommended for Gtk applications. I guess we are not using the built in functions to read/write files, therefore we are not a Gtk application in this regard.

When saving I get this error on the CLI:

Traceback (most recent call last):
  File "/app/lib/python3.10/site-packages/pdfarranger/pdfarranger.py", line 1199, in on_action_save
    self.save_or_choose()
  File "/app/lib/python3.10/site-packages/pdfarranger/pdfarranger.py", line 1208, in save_or_choose
    self.choose_export_pdf_name(savemode)
  File "/app/lib/python3.10/site-packages/pdfarranger/pdfarranger.py", line 1119, in choose_export_pdf_name
    root, ext = os.path.splitext(file_out)
  File "/usr/lib/python3.10/posixpath.py", line 118, in splitext
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType

TODO:

• Add xdg-run/gvfs to recipe.

[dreua]

Well I managed to do some debuggin inside the flatpak and the result is that Gtk.FileChooserNative just returns None as Filename when selecting a file from a samba share.

pdfarranger/pdfarranger/pdfarranger.py

Lines 1090 to 1119 in 118bfc1

	chooser = Gtk.FileChooserNative.new(title=title,
	parent=self.window,
	action=Gtk.FileChooserAction.SAVE,
	accept_label=_("_Save"),
	cancel_label=_("_Cancel"))
	chooser.set_do_overwrite_confirmation(True)
	if len(self.pdfqueue) > 0:
	f = self.save_file or self.pdfqueue[0].filename
	f_dir, basename = os.path.split(f)
	tempdir = f_dir.startswith(tempfile.gettempdir()) and f_dir.endswith(DOMAIN)
	if exportmode == 'ALL_TO_SINGLE':
	if f.endswith(".pdf") and not tempdir:
	chooser.set_filename(f) # Set name to existing file
	else:
	shortname, ext = os.path.splitext(basename)
	if self.export_file is None and tempdir:
	shortname = ""
	f = self.export_file or shortname + "-000" + ext
	f = self.get_cnt_filename(f)
	chooser.set_current_name(f) # Set name to new file
	chooser.set_current_folder(self.export_directory)
	filter_list = self.__create_filters(['pdf', 'all'])
	for f in filter_list[1:]:
	chooser.add_filter(f)
	response = chooser.run()
	file_out = chooser.get_filename()
	chooser.destroy()
	if response == Gtk.ResponseType.ACCEPT:
	root, ext = os.path.splitext(file_out)

According to the error message it runs through 1119 so the response must be "accept".

I also see this in my system log:

[da@David-UB ~]$ journalctl --follow
Jul 16 00:16:10 David-UB xdg-desktop-por[3381]: g_path_get_basename: assertion 'file_name != NULL' failed
Jul 16 00:16:10 David-UB xdg-desktop-por[3381]: g_path_get_dirname: assertion 'file_name != NULL' failed
Jul 16 00:16:10 David-UB xdg-desktop-por[3381]: Failed to register smb://192.168.[redacted]/asdf-002.pdf: Failed to open smb://192.168.[redacted]/asdf-002.pdf

[dreua]

Btw this is probably the same when opening, we just don't get to see an error message.

The documentation actually says:

The currently selected filename, or None if no file is selected, or the selected file can’t be represented with a local filename.

This led me to the suspicion that Gtk has issues finding a local filename for this file. This seems to be the issue: Selecting the file through some fancy looking samba mountpoint doesn't work but once you click manually through to the /run/user... path it works without issues. I'm tempted to say this is not our bug but Gtk's.

[dreua]

Found it:

• xdg-desktop-portal fails when selecting a remote URI from a Flatpak/Snap flatpak/xdg-desktop-portal#820

[canonex]

I imagined it was an upstream problem.
So now you have to wait for the problem to be solved and cascade, correct?

Thank you,
Riccardo

[dreua]

Yes, I'm afraid that's all we can do for now. I subscribed to both bugs, thankfully there already is a PR upstream. Once that is merged we could have a look whether that is going to cascade through the PDF Arranger flatpak or your distro, but I think it will be the latter. As a workaround you can give access through flatseal and then navigate the /run/... path in the open/close dialogs, that worked for me but it is of course cumbersome. I'd try creating a symlink from a convenient location, that might work just fine. (ln -s /run/... /home/wherever/you/want).

[canonex]

Thank you, for the moment I had the opportunity to switch to Debian package.
I'll wait the solution to the flatpack ecosystem, I suspect other software are affected.
Should we keep the bug open?

Thank you,
Riccardo

[dreua]

The fix for this has been merged and even backported to Gnome 45. Are you using Gnome 45? Not sure how fast those updates trickle through but it might be worth checking this again in a few weeks.

Original merge request: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67
Backport: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/129

[dreua]

@canonex could you check whether this is fixed with your latest os updates?

[canonex]

Option A is solved:
using the flatpack it is now possible to drag a pdf file from a smb share, using Nautilus, and drop onto Pdf arranger.

Option B and C are not solved:
it is not possible to load a file and it is not possible to save a file, both from smb shares.

Tests are done by installing the flatpack from scratch, without changing permissions on folders (eg. flatseal).

Thank you,
Riccardo