Flatpak apps can't get document portal

Ask Fedora
1

Flatpak apps can’t seem to get access to my filesystem. When I open a flatpak in the terminal it complains about the document portal.

Can’t get document portal: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected

When I try to save a page as PDF in firefox I get this error.

[Child 157, Main Thread] WARNING: Failed to create file monitor for /home/sputtre/.var/app/org.mozilla.firefox/config/glib-2.0/settings/keyfile: Unable to find default local file monitor type: ‘glib warning’, file /builddir/build/BUILD/firefox-134.0.2-build/firefox-134.0.2/toolkit/xre/nsSigHandlers.cpp:201
(/app/lib64/firefox/firefox:157): GLib-GIO-WARNING **: 10:32:51.091: Failed to create file monitor for /home/sputtre/.var/app/org.mozilla.firefox/config/glib-2.0/settings/keyfile: Unable to find default local file monitor type

When I try to run an application in bottles I get this error.

Traceback (most recent call last):
File “/app/share/bottles/bottles/frontend/views/bottle_details.py”, line 403, in execute
_(‘Launching “{0}”…’).format(dialog.get_file().get_basename())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: ‘NoneType’ object has no attribute ‘get_basename’

Any ideas how I could troubleshoot this? Should I report this on bugzilla or is this just a me problem?

2

What edition/spin is this? (Workstation, KDE, etc.)

3

Workstation

4

Please share the output of:

systemctl --user status xdg-{desktop,document}-portal.service
5

● xdg-desktop-portal.service - Portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
Drop-In: /usr/lib/systemd/user/service.d
└─10-timeout-abort.conf
Active: active (running) since Fri 2025-02-07 15:17:50 EST; 48s ago
Invocation: 2870241caa3c4704ba1a51aa9ae4af0a
Main PID: 3516 (xdg-desktop-por)
Tasks: 10 (limit: 37671)
Memory: 4.2M (peak: 5.1M)
CPU: 110ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-desktop-portal.service
└─3516 /usr/libexec/xdg-desktop-portal

Feb 07 15:17:50 fedora systemd[2251]: Starting xdg-desktop-portal.service - Portal service…
Feb 07 15:17:50 fedora systemd[2251]: Started xdg-desktop-portal.service - Portal service.

× xdg-document-portal.service - flatpak document portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-document-portal.service; static)
Drop-In: /usr/lib/systemd/user/service.d
└─10-timeout-abort.conf
Active: failed (Result: exit-code) since Fri 2025-02-07 15:17:50 EST; 49s ago
Duration: 4ms
Invocation: b05cc3471fd242418644afb936ad0caf
Process: 3533 ExecStart=/usr/libexec/xdg-document-portal (code=exited, status=6)
Main PID: 3533 (code=exited, status=6)
Mem peak: 1.9M
CPU: 14ms

Feb 07 15:17:50 fedora systemd[2251]: Starting xdg-document-portal.service - flatpak document portal service…
Feb 07 15:17:50 fedora systemd[2251]: Started xdg-document-portal.service - flatpak document portal service.
Feb 07 15:17:50 fedora xdg-document-portal[3573]: fusermount3: failed to access mountpoint /run/user/1000/doc: Permission denied
Feb 07 15:17:50 fedora xdg-document-portal[3533]: error: fuse init failed: Can’t mount path /run/user/1000/doc
Feb 07 15:17:50 fedora systemd[2251]: xdg-document-portal.service: Main process exited, code=exited, status=6/NOTCONFIGURED
Feb 07 15:17:50 fedora systemd[2251]: xdg-document-portal.service: Failed with result ‘exit-code’.

6

Are you using btrfs-assistant?

7

I have never heard of it until now, but I checked and I do have it installed on my system.

8

It has caused problems like this in the past. Please run:

ps aux | grep portal

I’m mainly looking to see if any xdg-*-portal processes are running as root.

9

sputtre 2816 0.0 0.0 530980 6908 ? Ssl 17:28 0:00 /usr/libexec/ibus-portal
sputtre 3058 0.0 0.0 768552 13400 ? Sl 17:28 0:00 /usr/libexec/xdg-desktop-portal
sputtre 3070 0.0 0.0 754676 6404 ? Sl 17:28 0:00 /usr/libexec/xdg-document-portal
root 3096 0.0 0.0 2576 1940 ? Ss 17:28 0:00 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
sputtre 3104 0.0 0.0 653892 22496 ? Sl 17:28 0:00 /usr/libexec/xdg-desktop-portal-gnome
sputtre 3145 0.0 0.0 635352 22772 ? Sl 17:28 0:00 /usr/libexec/xdg-desktop-portal-gtk
sputtre 3519 0.0 0.0 842196 13868 ? Ssl 17:28 0:00 /usr/libexec/xdg-desktop-portal
sputtre 3603 0.0 0.1 1097436 39860 ? Ssl 17:28 0:00 /usr/libexec/xdg-desktop-portal-gnome
sputtre 3646 0.0 0.0 635448 22056 ? Ssl 17:28 0:00 /usr/libexec/xdg-desktop-portal-gtk
sputtre 11088 0.0 0.0 230340 2164 pts/0 S+ 22:57 0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox --exclude-dir=.venv --exclude-dir=venv portal

10

So you have a duplicate set of processes running, but not as root (fusermount3 is SUID, so it being root is normal).

I have no idea if that’s still related to btrfs-assistant, but you could try uninstalling it. Though, it doesn’t seem like it autostarts(?), so I guess it couldn’t do anything if it’s not running.

It shouldn’t be possible for two instances of e.g. xdg-desktop-portal to be running as the same user, as they should both connect to the same user bus, and one would exit. It probably could only happen if something is spinning up a separate D-Bus session bus.

One diagnostic that might be helpful is to check systemd-cgls, search for the two instances of that process (use /), and see where they are in the hierarchy. The proper one should look like this:

-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service …
│   │ ├─session.slice
[...]
│   │ │ ├─xdg-desktop-portal.service
│   │ │ │ └─2996 /usr/libexec/xdg-desktop-portal

I’m curious about the other one.

11

As you said, the first one I see is:

-.slice
├─user.slice
│ └─user-1000.slice
│ ├─user@1000.service …
│ │ ├─session.slice
[…]
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3545 /usr/libexec/xdg-desktop-portal

The other one spawns from the gnome session manager:

-.slice
├─user.slice
│ └─user-1000.slice
│ ├─user@1000.service …
│ │ ├─app.slice
[…]
│ │ │ ├─app-gnome\x2dsession\x2dmanager.slice
│ │ │ │ └─gnome-session-manager@gnome.service
│ │ │ │ ├─2410 /usr/libexec/gnome-session-binary --systemd-service --sessio…
│ │ │ │ ├─2825 dbus-daemon --nofork --print-address 4 --session
│ │ │ │ ├─2856 /opt/paloaltonetworks/globalprotect/PanGPUI
│ │ │ │ ├─2981 /usr/libexec/xdg-desktop-portal
│ │ │ │ ├─3004 /usr/libexec/xdg-document-portal
│ │ │ │ ├─3011 /usr/libexec/xdg-permission-store
│ │ │ │ ├─3026 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,su…
│ │ │ │ ├─3036 /usr/libexec/xdg-desktop-portal-gnome
│ │ │ │ ├─3076 /usr/libexec/gvfsd
│ │ │ │ └─3095 /usr/libexec/xdg-desktop-portal-gtk

12

Something is probably using dbus-launch or dbus-run-session to create a new session bus, and then the portal processes are dbus-activated by that dbus-daemon. I’m suspecting this may be the culprit:

Do you know how PanGPUI is started exactly? I’m assuming ~/.config/autostart (or /etc/xdg/autostart/, but I’m a little surprised that it didn’t get placed in its own cgroup.

13

You are on the money. PanGPUI.desktop lives in /etc/xdg/autostart. It contains the line:

Exec=dbus-run-session /opt/paloaltonetworks/globalprotect/PanGPUI

This a janky application from top to bottom and I don’t even need it anymore, so I will just get rid of it unless doing some more troubleshooting would be informative.

1 Like