I'm not able to open links and files from inside flatpak contexts anymore. I have several apps that are able to open links (in my case Obsidian) or files (Zotero). I assume they use something like xdg-open. But nothing happens. When I click on links in Obsidian, I can see this when I use flatpak run ... but nothing else happens:

Opening URL: <desired URL is here>

In Zotero I could open files before and a system dialogue was shown where I could choose an application. But nothing happens now.

Using xdg-open <URL or file> works as expected outside flatpak of course.
I'm using Flatpak 1.11.1 on Archlinux.

I'm very sorry to post such a vague issue and I'm sorry if this is off-topic, but I don't know, where I can find help instead.

xdg-email(1) documents the positional parameters for the address as repeatable, but this implementation only seems to take the first one.

xdg-desktop-portal 0.9 switched from attachments as an array of URIs to attachment_fds as an array of fds. but flatpak-xdg-utils 1.0.0 switched from attachments as an array of URIs to attachments as an array of fds.

flatpak-xdg-utils should send attachment_fds instead.

The reference xdg-email(1) is documented as accepting these as equivalent:

xdg-email --subject="Make Money Fast" --body="Spam" [email protected]
xdg-email "mailto:[email protected]?subject=Make%20Money%20Fast&body=Spam"

but I don't see any code in xdg-email to handle the latter.

I originally reported this against Transmission (flathub/com.transmissionbt.Transmission#4) because I thought the bug was there, but after investigation it seems not.

Inside a Flatpak sandbox:

bash-4.3$ xdg-open file:///home/mathieu/Downloads
bash-4.3$ 

The command exits successfully (it returns 0) and silently but nothing happens.

With the "classic" (i.e not Flatpak) xdg-open, a Nautilus window pops up showing the folder.

As part of flatpak/xdg-desktop-portal#105, and to prevent a security issue where the sandbox could be escaped at a filesystem level, the OpenURI method of this portal stopped handling file:// URIs, meaning that external files now must be accessed either via the documents portal or by using a local the newly added OpenFile method, which accepts a file descriptor instead of the URI.

From what I can see in https://github.com/flatpak/flatpak-xdg-utils/blob/master/src/xdg-open.c, this implementation of xdg-open does not treat native and non-native URIs differently (they all go through the OpenURI portal), so this would need to be adapted for file:// URIs to continue working

When using flatpak-spawn I get "no DISPLAY environment variable specified" though DISPLAY is in env and is correct

[dk@sys dk]$ echo $DISPLAY
:20

it works as expected if I enter bash and then run firefox with DISPLAY set

[dk@sys dk]$ distrobox-host-exec bash
[dk@localhost dk]$ DISPLAY=:20 firefox
flatpak-spawn --host firefox
Error: no DISPLAY environment variable specified

But adding the env works

flatpak-spawn --host --env=DISPLAY=$DISPLAY firefox

Running in an archlinux container

pacman -Q flatpak-xdg-utils
flatpak-xdg-utils 1.0.5-1

It would be nice to have some option like --copy-env to automatically set all current environment variables for spawned process. This way it would behave more like a child process, that inherits current environment.
App-launching apps like Steam or Lutris would benefit from it a lot, since it would allow to easily restrict permissions for child app or game.

Trying to spawn a shell gives some unexpected output.

sh-4.3$ flatpak-spawn sh
sh: cannot set terminal process group (-1): Inappropriate ioctl for device
sh: no job control in this shell

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.12.7

What Linux distribution are you using?

Linux Mint

Linux distribution version

Linux Mint 21 Vanessa base: Ubuntu 22.04 jammy

What architecture are you using?

x86_64

How to reproduce

This issue occurs with com.borgbase.Vorta which is a GUI frontend for the backup tool borg. Borg allows mounting a backup repository using fuse. For use in the flatpak distribution of Vorta libfuse is installed as configured here and wrapped with a small script that runs fusermount through flatpak-spawn. This usually works fine but not on my machine as reported on borgbase/vorta#1424.

Borg calls backups that are stored in the same repository archives. When the vorta application runs borg mount a warning is occurs:

** (flatpak-spawn:46): WARNING **: 12:49:29.683: Unable to read struct signalfd_siginfo: Bad file descriptor

For some archives mounting works nonetheless, for others it doesn't. Since this seems to be an issue of flatpak-spawn the vorta devs redirected me to this bug tracker.
Thanks.

Expected Behavior

please see borgbase/vorta#1424

Actual Behavior

please see borgbase/vorta#1424

Additional Information

No response

Linux distribution and version

Arch Linux

Flatpak version

Flatpak 1.11.2

Description of the problem

While building flatpaks using flatpak-builder flatpak there are a lot (hundreds) of warnings related to flatpak-spawn printed in output at various stages:

** (flatpak-spawn:29): WARNING **: 11:28:11.436: Unable to read struct signalfd_siginfo: Bad file descriptor
...
** (flatpak-spawn:59): WARNING **: 11:37:10.183: Unable to read struct signalfd_siginfo: Bad file descriptor
...
** (flatpak-spawn:78): WARNING **: 11:45:53.263: Unable to read struct signalfd_siginfo: Bad file descriptor
...
** (flatpak-spawn:101): WARNING **: 11:45:59.814: Unable to read struct signalfd_siginfo: Bad file descriptor

Beside of the above the build succeeds.

Steps to reproduce

Build flatpak using flatpak-builder flatpak, i.e
flatpak run org.flatpak.Builder build org.flatpak.Builder.yml

flatpak-spawn currently catches various signals by using signal() with a handler that posts an event to the main loop via g_idle_add(), but I'm fairly sure that isn't guaranteed to be async-signal safe.

Since Flatpak is Linux-specific (and therefore so is flatpak-spawn?), I think this can probably be most easily solved by using a signalfd. I have a prototype implementation, but I haven't tested it yet.

As also stated in this issue, electron made and chromium based apps need that executable to read/configure various system properties, for example mimetype handling.

As mentioned in https://mail.gnome.org/archives/desktop-devel-list/2019-February/msg00064.html I wonder whether this xdg-email implementation would be useful even in non-sandboxed contexts. As long as xdg-desktop-portal is installed, a container framework like Flatpak or Snap is not actually required - host programs can equally well talk to xdg-desktop-portal via D-Bus themselves.

As noted in https://mail.gnome.org/archives/desktop-devel-list/2019-February/msg00057.html, the reference implementation of xdg-email (the big shell script) is brittle and full of special cases, so programs that want to send email via a CLI might be better off using this one than the shell script.

I've packaged flatpak-xdg-utils for Debian 10, to make it more straightforward to build Flatpak runtimes out of Debian 10+
packages (conceptually similar to Fedora's runtimes). At the moment the flatpak-xdg-utils tools are installed into /usr/libexec rather than onto the PATH, and containers that want them in the PATH are expected to create their own symlinks, but there's no reason there couldn't be a symlink at /usr/bin/xdg-desktop-portal-email or something.

Trying to open a persistent directory (specified in --persist=) from within a flatpak (that has no real homedir access) with xdg-open $HOME/<directory> does nothing, although echo $? prints 0. It this expected behaviour?

Actually, I expected it to be equivalent to xdg-open $HOME/.var/app/<app-id>/<directory> in this case.

flatpak-spawn --host sudo echo
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

I've also noticed some apps like neovim are not rendering properly and glitch when being resized. It feels like working in serial console in general.

This works:

$ flatpak-spawn  --env=GIO_USE_VFS=local --env=G_MESSAGES_DEBUG=all --sandbox-expose-path=/home/hadess/.var/app/org.gnome.Books/cache/gnome-desktop-thumbnailer/gstreamer-1.0 --env=GST_REGISTRY_1_0=/home/hadess/.var/app/org.gnome.Books/cache/gnome-desktop-thumbnailer/gstreamer-1.0/gstreamer-1.0.registry --watch-bus --sandbox --no-network --sandbox-expose-path=/home/hadess/.var/app/org.gnome.Books/sandbox/gnome-desktop-thumbnailer-9NAMZ0 --sandbox-expose-path-ro="/home/hadess/Documents/e-Books tests/Pepper___Carrot_-_épisodes_13_-_webp.cbz" ls

but this fails:

$ flatpak-spawn --clear-env --env=LANG=en_GB.UTF-8  --env=GIO_USE_VFS=local --env=G_MESSAGES_DEBUG=all --sandbox-expose-path=/home/hadess/.var/app/org.gnome.Books/cache/gnome-desktop-thumbnailer/gstreamer-1.0 --env=GST_REGISTRY_1_0=/home/hadess/.var/app/org.gnome.Books/cache/gnome-desktop-thumbnailer/gstreamer-1.0/gstreamer-1.0.registry --watch-bus --sandbox --no-network --sandbox-expose-path=/home/hadess/.var/app/org.gnome.Books/sandbox/gnome-desktop-thumbnailer-9NAMZ0 --sandbox-expose-path-ro="/home/hadess/Documents/e-Books tests/Pepper___Carrot_-_épisodes_13_-_webp.cbz" ls
error: Invalid byte sequence in conversion input

Similar to what it was reported in #1, the ComposeEmail method of this portal will stop handling file:// URIs directly, and will now require passing a list of file descriptors instead, meaning that the implementation https://github.com/flatpak/flatpak-xdg-utils/blob/master/src/xdg-email.c will need to be updated accordingly.

I am attempting to update the Tuxpaint Flatpak. The latest version uses these two tools to install icons & desktop files to the correct locations; however, they are not available in the SDK.

Of course, I can install (and clean up) the real ones. But perhaps providing the latter would be a way to, in future, support applications exporting new desktop files at runtime?

The reference (shell script) implementation of xdg-email can take more than one attachment by repeating --attach, but this implementation treats each --attach as overwriting the previous one.

Fixing this will require a bit of refactoring (turning --attach into a G_OPTION_ARG_FILENAME_ARRAY, and iterating over the array to populate an array of handles) so I'd prefer to get #51 in first.

Reproduced with Flatpak 0.99.3 on Fedora Silverblue 28.

TL;DR: Run this, then try shutting down your system:

flatpak run --command='flatpak-spawn' org.gnome.Photos sleep 30

(Any app works; I just randomly picked Photos here.)

systemd will hang for 2 minutes saying it's stuck waiting for a stop job.

• Another, less drastic way to see the same issue would be to run the above, then Ctrl-C. sleep will still be running.
• Any app works; I just randomly picked Photos.
• Any other command passed to flatpak-spawn can reproduce the issue.
• If you watch the system monitor, you'll see that every time sleep runs, another flatpak-spawn and bwrap process will appear and stay around...even after the sleep command finishes.

Linux distribution and version

Fedora 34 beta

Flatpak version

1.10.2

Description of the problem

I use the flatpak of Pika backup. When I needed to check something on the command line I realized I do not have borgbackup installed on my client. So I tried using borg from the flatpak. It seems to work fine but I get multiple warnings from flatpak-spawn like this:

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

Steps to reproduce

1. use Pika to create a backup at ssh://user@server:/~/backup
2. alias borg='flatpak run --command=borg org.gnome.World.PikaBackup'
3. borg mount user@server:/~/backup ~/borg