Setting custom editor and file associations doesn't work with FileZilla flatpak version

[baermathias]

I am using FileZilla flatpak version 3.45.1 and getting the following error when trying to open a file or changing the custom editor:

The file 'index.html' cannot be opened: The associated program (/usr/bin/code) could not be found. Please check your filetype associations.

Even though I can run /usr/bin/code from the command line. It also worked in the old version, which was an application directory and not a flatpak.

[TingPing]

It can never work, its sandboxed. The only thing it could do is download the file and then open it with your default editor.

[baermathias]

So the solution is to give the FileZilla Flatpak version certain access to a directory or app?

[TingPing]

You'd have to patch it to use flatpak-spawn --host to escape the sandbox and execute apps on the host.

[baermathias]

Why can't it be released the same way the original app is working?

[TingPing]

Because flatpak is a sandbox. It isolates this app from other apps.

[baermathias]

How about handling it in a similar way as snap does? With a snap I would get a message before the editor would be executed:

Allow opening file?
Allow snap "filezilla" to open file "/path/to/code_editor_name"?
This dialog will close automatically after 5 minutes of inactivity.

[TingPing]

That could be plausible and would be a discussion to have here: https://github.com/flatpak/xdg-desktop-portal/

But any solution there would require source changes to Filezilla to use said portal.

It also introduces complications since what exists in the sandbox != what exists on the host.

[antistress]

I'd like to precise regarding org.filezillaproject.Filezilla settings :
usr/bin/gedit which is pre-filled in File editing box doesn't work, nor php usr/bin/libreoffice in Filetype associations box
Also instead of usr/bin/gedit, selecting "use default system text editor for text files" (or similar : I use a french version) doesn't work either : An assertion failed !

ASSERT INFO:
./src/common/filefn.cpp(1609): assert "!szFile.empty()" failed in wxFindFileInPath(): empty file name in wxFindFileInPath

BACKTRACE:
(null)

Thanks

[antistress]

Hi,
I have no idea how it's implemented but if you take Pitivi video editor in Flatpak for instance, once your project is rendered it asks you to choose an application to play the video (see screenshot below).

Note sure if it can help.

Thanks.

[bilelmoussaoui]

Hi,
I have no idea how it's implemented but if you take Pitivi video editor in Flatpak for instance, once your project is rendered it asks you to choose an application to play the video (see screenshot below).

Note sure if it can help.

Thanks.

They are using the OpenURI portal https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI

[paddylandau]

I've just upgraded my system to Ubuntu 20.04, and I've installed FileZilla as a flatpak.

Unfortunately, I now have this same problem.

If it's not possible to get FileZilla as a flatpak to recognise the editor, it makes the flatpak release useless to me. I'll have to revert to the PPA, which I really prefer to avoid (PPA clutter). EDIT: There's no PPA; you have to download from the website, which makes it even harder :(

Given how much easier snap is to install and use than flatpak, maybe we could see FileZilla released a a snap?

[paddylandau]

If it's of any help to you, I have figured out a simple workaround. (Edited 2023-08-16 and 2023-08-22 with new information.)

In my case, I use the text editor gedit, which is located on on my default path.

My workaround is as follows. Remember that when you change the sandbox settings, you need to close FileZilla before it takes effect.

1. Give FileZilla permission to bypass the sandbox. Naturally, you have to trust FileZilla before you do this. Either Flatseal > Session Bus > Talks > add org.freedesktop.Flatpak, or issue the following command in the terminal:

flatpak --user override --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla

2. You also have to let FileZilla access /tmp, because it seems to ignore $TMPDIR. Either Flatseal > Filesystem > Other files > /tmp, or issue the following command in the terminal:

flatpak --user override --filesystem=/tmp org.filezillaproject.Filezilla

3. Create a script named filezilla-edit. Ensure that it is executable. This script contains just two lines:

#!/usr/bin/env bash
flatpak-spawn --host gedit "${@}"

4. In FileZilla, go to Edit > Settings > File editing > Use custom editor > /path/to/filezilla-edit (replace /path/to with your actual path to filezilla-edit).

This does the job.

Notes about the script:

• You can of course use a different name for your script.
• You can use a different shell instead of bash, e.g. sh (if necessary, modify the syntax as appropriate). But I found that when I didn't specify a shell, it didn't work; I don't know why.
• Replace gedit with whichever GUI text editor you prefer.

[taneharre]

I'll link to this from Flathub as well.

[waiting-for-signs]

unfortunately the solution above didn't work in my case. I could open local files with the editor set in filezilla-edit, but I couldn't edit the files on the server.
So I dropped the flatpak-filezilla and used the very old .deb version ... a nice mess.

[paddylandau]

unfortunately the solution above didn't work in my case. I could open local files with the editor set in filezilla-edit, but I couldn't edit the files on the server.

I've had another look at my setup, and I notice that I had added /tmp to the flatpak permissions. Removing that prevents the editor from loading the remote file.

I have edited my previous comment; see point 2.

Please try again to see if it works.

[waiting-for-signs]

oh, wow - this fast :))))
Thank you @paddylandau , this did the trick. It works and I don't have to use the old filezilla. Thanks a lot 👍

And I forgot to mention that I had to close filezilla so the changes could take effect! Maybe you could mention this in your solution - to close or "restart" filezilla after the changes.

[RasheedAZ]

Thank you @paddylandau , works for me now too :) However, I'd like to use Gnome Text Editor to edit but when I replace gedit with flatpak run org.gnome.TextEditor in the script, the file opens in it but it's empty!

Would appreciate any help or advice with this. Thanks.

Update:
No worries. Had to also give Gnome Text Editor access to /tmp in Flatseal.

[Matige]

Edit: The instructions presented in this comment are incorrect. Check #40 (comment).

Thank you @paddylandau for the tips, they directed me to a simpler solution.

1. There is no need to create a script to run the flatpak-spawn process. As Use custom editor type:

/usr/bin/flatpak-spawn --host gedit %f

2. It isn't necessary to grant permissions to the /tmp directory. Flatpak uses $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID, so after checking the contents of $XDG_RUNTIME_DIR (echo $XDG_RUNTIME_DIR - in my example /run/user/1000), the full command to type as Use custom editor is:

/usr/bin/flatpak-spawn --host gedit /run/user/1000/.flatpak/org.filezillaproject.Filezilla%f

Summary:

1. Close all opened FileZilla windows.
2. Grant Filezilla access to the org.freedesktop.Flatpak D-Bus interface:

flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla

3. Open FileZilla, go to Edit > Settings > File editing > Use custom editor and set (replace /run/user/1000 with the result of echo $XDG_RUNTIME_DIR):

/usr/bin/flatpak-spawn --host gedit /run/user/1000/.flatpak/org.filezillaproject.Filezilla%f

[paddylandau]

Thank you, @Matige . Unfortunately, this doesn't work for me!

I haven't used FileZilla to edit a file for a long time, so before I looked at your alternative, I tested to see if my solution still worked.

It didn't! I could successfully edit a local file, but not a remote file. In other words, I was failing to access the file downloaded into /tmp.

Problem with my solution

I suspect that my new problem (accessing the remote file) is because when I first created the solution, I wasn't using the Flatpak version of Gedit, whereas now I am. I think that Gedit needs an extra permission to access Flatpak's pseudo $TMP, but I don't know how to go about that. I'll have to test when I have more time.

Problem with your solution

Naturally, I have tested your method. Unfortunately, it's even worse: With your method, I can access neither the local nor the remote file.

The problem with the local file is because you have specified the full path starting with /run, but of course that's not where local files are. The custom editor should be use just %f, not the full path, otherwise local files cannot be edited.

Note: My $XDG_RUNTIME_DIR is the same as yours: /run/user/1000.

I'll post back here if I manage to work out how to use the Flatpak version of Gedit with FileZilla.

[Matige]

@paddylandau, I fully agree with you. My solution isn't working properly. I have explored the issue too little.

For systems other than Windows and Mac, FileZilla sets the location of temporary files as follows:

#else
	if (!ret.SetPath(GetEnv("TMPDIR"))) {
		if (!ret.SetPath(GetEnv("TMP"))) {
			if (!ret.SetPath(GetEnv("TEMP"))) {
				ret.SetPath(L"/tmp");
			}
		}
	}
#endif

The TEMPDIR, TMP and TEMP environment variables are checked. If the directory exists, it is set as the directory for temporary files. Otherwise /tmp is set.

Flatpak has introduced support for shared temporary directory as of version 1.11.1 (flatpak/flatpak@b65b3f6). It maps the directory $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/tmp and in the container it is visible as /tmp. This is the reason why editing external files (stored in the /tmp directory) worked in my workaround.

It would seem that the solution is to set the TEMPDIR environment variable to $XDG_RUNTIME_DIR/.flatpak/org.filezillaproject.Filezilla/tmp. However, it turned out that flatpak app doesn't have access to this directory, so FileZilla will set the temporary directory to /tmp. As a result, the edited files are downloaded to $XDG_RUNTIME_DIR/.flatpak/org.filezillaproject.Filezilla/tmp, but the /tmp directory is passed as the %f parameter, so an empty file is opened.

So I reached out to the Flatpak documentation (I should start there).

One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. This includes:

• No access to any host files except the runtime, the app, ~/.var/app/$FLATPAK_ID, and $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Only the latter two being writable.

[...]

If an application uses $TMPDIR to contain lock files you may want to add a wrapper script that sets it to $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

In that case, the solution is to set the TEMPDIR environment variable for FileZilla:

flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.filezillaproject.Filezilla

Now the edited files are downloaded to ${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla, this directory is also passed as parameter %f to the editor. Of course, in this case we set Use custom editor to /usr/bin/flatpak-spawn --host gedit %f.

Final summary

1. Close all opened FileZilla windows.
2. Grant Filezilla access to the org.freedesktop.Flatpak D-Bus interface:

flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla

3. Set the TMPDIR environment variable:

flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.filezillaproject.Filezilla

4. Open FileZilla, go to Edit > Settings > File editing > Use custom editor and set:

/usr/bin/flatpak-spawn --host gedit %f

Reflections

One might ask why not simply grant FileZilla access to the /tmp directory. This breaks the idea of Flatpak sandboxing. The /tmp directory is accessible to everyone with 777 chmod.

There is still the issue of accessing the temporary directory from another Flatpak application (such as gedit installed as flatpak). The flatpak application only has access to its own directory, so gedit can access $XDG_RUNTIME_DIR/app/org.gnome.gedit, but not $XDG_RUNTIME_DIR/app/org.filezillaproject.Filezilla. Therefore, the opened file will be empty. I don't know if there is any correct way to solve this problem. Personally, I see two solutions:

1. Try granting gedit access to the FileZilla application directory. I'm not sure if this will work.

flatpak --user override --filesystem="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.gnome.gedit

2. Create a temporary (exchange) directory elsewhere and give it permissions from both flatpak applications.

[paddylandau]

@Matige — Thank you so much! Thanks to your investigation, I have managed to make it work. Here are the steps:

1. Allow FileZilla to bypass the sandbox.

flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla

2. Ask FileZilla to use its own pseudo-/tmp.

flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}"/app/org.filezillaproject.Filezilla org.filezillaproject.Filezilla

3. If you use the flatpak version of Gedit, allow it to access FileZilla's temporary folder.

flatpak override --user --filesystem="${XDG_RUNTIME_DIR}"/app/org.filezillaproject.Filezilla org.gnome.gedit

4. Set FileZilla to call Gedit. Note that you don't need to add %f to the command, as the files are added automatically.
   FileZilla > Edit > Settings > File editing > Use custom editor > /usr/bin/flatpak-spawn --host gedit

[antistress]

Hi, any chance to have this feature working out of the box of the flatpak version ?
Thanks !

[TingPing]

No, the entire feature is incompatible with running in a sandbox.

[antistress]

No, the entire feature is incompatible with running in a sandbox.

Thanks for the answer.

However I thought that a portal could be used as shown in #40 (comment) ?

[TingPing]

If the feature is redesigned upstream, sure some things can work. But that isn't how it currently works and would have less flexibility than how it currently works.

[antistress]

Thanks