Noratek BLOG

Flatpak apps won't start on Fedora — a hung Keybase FUSE mount (/keybase)

Published 5 August 2026

date
env
linux Fedora 44 (kernel 7.1.5, GNOME 50, Framework Laptop 16 AMD, Keybase 6.6.3) macos N/A
tags

You click a Flatpak application — in my case Extension Manager — and nothing happens. No window, no error, no crash dialog. Launch it again and still nothing, except that another dead process quietly piles up in the background. The application is innocent: the real culprit is a dead FUSE mount elsewhere on the system, which every Flatpak sandbox startup walks into and blocks on.

This HOWTO uses Keybase’s /keybase redirector as the concrete example, but the diagnosis applies to any unresponsive FUSE mount (sshfs, rclone, gocryptfs, a stale network mount).

Notation: replace <n> with the FUSE connection number you find, and <pid> with a real process ID. Commands use $(id -u) instead of a hard-coded UID.

Symptoms

  • A Flatpak app launched from the app grid never opens a window — silently.

  • Running it from a terminal produces no output at all and never returns:

    Terminal window
    flatpak run com.mattjakeman.ExtensionManager

  • Each attempt leaves a flatpak run process behind. After a few tries you have several, all stuck since different times:

    Terminal window
    $ ps aux | grep flatpak
    user  39287  0.0  0.0 420944 19508 ?  Sl  12:50  0:00 /usr/bin/flatpak run --branch=stable ... com.mattjakeman.ExtensionManager
    user  41350  0.0  0.0 420912 19708 ?  Sl  12:57  0:00 /usr/bin/flatpak run --branch=stable ... com.mattjakeman.ExtensionManager
    user  43893  0.0  0.0 420924 19408 ?  Dl  12:59  0:00 flatpak run com.mattjakeman.ExtensionManager

  • The processes cannot be killed. kill, kill -9, timeout, closing the terminal — nothing removes them. Note the D in the STAT column above.

  • ls /keybase (or any access to the dead mount) hangs forever too.

  • Every Flatpak app is affected, not just the one you noticed.

Root cause

Two facts combine into this deadlock.

1. A FUSE filesystem whose daemon stops answering blocks its callers forever. FUSE requests are served by a userspace daemon. When that daemon is alive but no longer replying, the kernel parks the calling process in the D state — uninterruptible sleep — waiting in request_wait_answer(). A process in D state ignores every signal, including SIGKILL. It is not a hang you can kill your way out of; it is a thread waiting on I/O that will never complete.

In my case the stuck mount was /keybase, served by keybase-redirector running as root. The KBFS daemon itself (kbfsfuse, on /run/user/$(id -u)/keybase/kbfs) was perfectly healthy — only the root-level redirector had gone deaf.

2. Flatpak inspects every mount point when it builds a sandbox. Before starting an application, Flatpak reads the host mount table to decide what to bind-mount into the sandbox namespace, and stats the filesystems it finds. One of those statfs() calls lands on /keybase, blocks, and the launch never proceeds — the sandbox is never even created, which is why you see zero output: the application binary was never reached.

The result is a system where one dead FUSE mount silently disables Flatpak entirely, while the rest of the desktop keeps working normally, so nothing points you at the real cause.

Diagnosis

1. Confirm the process is stuck in uninterruptible sleep. Look for D in STAT:

Terminal window
ps -o pid,stat,cmd -C flatpak

2. Ask the kernel what it is waiting for. This is the decisive step:

Terminal window
cat /proc/<pid>/wchan; echo

Output request_wait_answer means: blocked on a FUSE request that is never answered. That single word identifies the whole class of problem.

3. Find out which syscall, on which file descriptor:

Terminal window
cat /proc/<pid>/syscall

The first number is the syscall. On x86-64, 137 is statfs and 138 is fstatfs; the second field is the file descriptor in hex. Resolve it to a path:

Terminal window
# 0x48 = 72
ls -l /proc/<pid>/fd/72
Terminal window
l---------. 1 user user 64 Aug  5 13:05 /proc/<pid>/fd/72 -> /keybase

There is the guilty mount.

4. List FUSE mounts and confirm the one that hangs:

Terminal window
findmnt -t fuse,fuse.rclone,fuse.portal,fuse.sshfs -o TARGET,SOURCE,FSTYPE
timeout 5 stat -f /keybase >/dev/null; echo "exit $?"

An exit code of 124 means timeout had to kill it: the mount is dead. A healthy mount returns 0 instantly. Test each FUSE mount this way — it isolates the bad one in seconds and clears the innocent ones (my rclone Dropbox mount answered fine).

Solution

Step 1 — Unblock the system without rebooting

You cannot kill a D-state process, but you can tell the kernel to abandon the FUSE connection it is waiting on. Every connection is exposed under /sys/fs/fuse/connections/. Find the one owned by the right user — the Keybase redirector runs as root, so its directory is owned by root:

Terminal window
ls -l /sys/fs/fuse/connections/

Then abort it:

Terminal window
echo 1 | sudo tee /sys/fs/fuse/connections/<n>/abort

All pending requests fail immediately, and every process frozen on that mount is released at once. Nothing else on the system is disturbed — this is the standard, supported way out of a wedged FUSE mount.

The connection number changes at every mount. Always look it up; never reuse an old one.

Step 2 — Unmount and stop Keybase

Terminal window
run_keybase -k
sudo umount -l /keybase 2>/dev/null
fusermount -uz /run/user/$(id -u)/keybase/kbfs 2>/dev/null
pkill -f keybase; pkill -f kbfsfuse

Do the abort in step 1 first: run_keybase -k touches /keybase itself and will hang in exactly the same way if the mount is still wedged.

Step 3 — Remove Keybase completely (optional)

I chose to uninstall it rather than wait for the redirector to wedge again. KBFS data lives on Keybase’s servers, so nothing local needs saving:

Terminal window
sudo dnf remove -y keybase
sudo rm -f /etc/yum.repos.d/keybase.repo
rm -rf ~/.cache/keybase ~/.config/keybase ~/.local/share/keybase ~/.config/Keybase
rm -f ~/.config/autostart/keybase_autostart.desktop
sudo rm -rf /opt/keybase /keybase
systemctl --user daemon-reload

Step 4 — Verify

Terminal window
grep -i keybase /proc/mounts || echo "no keybase mount left"
flatpak run com.mattjakeman.ExtensionManager

The application should now open normally. Check that the sandbox is really being built:

Terminal window
ps aux | grep -E "bwrap|extension-manager" | grep -v grep

Seeing a bwrap ... -- extension-manager line plus the actual extension-manager process means Flatpak got past the mount enumeration that used to block it.

Step 5 — Clean up leftovers

Old stuck launches resume execution the moment you abort the FUSE connection, so you may end up with ghost instances. Their command line has changed by then (from flatpak run com.example.App to bwrap ... -- app-binary), so a pkill on the application ID will miss them:

Terminal window
ps aux | grep bwrap | grep -v grep
kill <pid>

Notes and good practices

  • D state is the tell. Whenever a process ignores kill -9, stop trying to kill it and read /proc/<pid>/wchan instead. It names the kernel function being waited on and usually identifies the subsystem immediately.

  • This is not specific to Keybase. Any FUSE mount that stops answering — sshfs over a dropped link, rclone against an unreachable remote, a stale gocryptfs — will disable Flatpak the same way. The diagnosis and the abort fix are identical.

  • Aborting a connection is safe for the rest of the system, but in-flight writes to that filesystem are lost. For a read-mostly mount like a Keybase redirector there is nothing at stake; for a mount you were actively writing to, expect to lose the pending data.

  • Can a hung FUSE mount crash or reboot your machine? Almost certainly not, and it is worth knowing why. A stuck FUSE daemon is userspace: it parks processes in D state and leaves them there indefinitely, which is annoying but inert. The Fedora kernel does not even ship the hung-task detector that could escalate it — CONFIG_DETECT_HUNG_TASK is not set, so kernel.hung_task_panic does not exist. The only theoretical route to a reboot is a kernel bug in the FUSE path producing an oops, which on a default Fedora system (kernel.panic_on_oops = 1, kernel.panic = 10) does reboot the machine ten seconds later — but an oops leaves a loud trace. Check before blaming it:

    Terminal window
    journalctl -p err -g "Oops|BUG:|kernel panic" --since "-7 days"

    If that comes back empty and the journal simply stops at the moment of the reboot, the kernel never got a chance to write anything, which points at a firmware- or hardware-level reset (machine check, PCIe/Sync Flood, a power event), not at a userspace daemon.

  • Blaming the visible app wastes time. The natural instinct is to reinstall the application that “won’t start”. Reinstalling would have changed nothing here; the one useful question was which mount is Flatpak stuck on.

Quick reference

Terminal window
# 1. Confirm: process in D state, waiting on FUSE
ps -o pid,stat,cmd -C flatpak
cat /proc/<pid>/wchan; echo          # -> request_wait_answer


# 2. Identify the dead mount
cat /proc/<pid>/syscall              # 137/138 = statfs/fstatfs, 2nd field = fd (hex)
ls -l /proc/<pid>/fd/<fd>            # -> /keybase
timeout 5 stat -f /keybase; echo $?  # 124 = dead


# 3. Unblock without rebooting (root-owned connection = the redirector)
ls -l /sys/fs/fuse/connections/
echo 1 | sudo tee /sys/fs/fuse/connections/<n>/abort


# 4. Stop and unmount Keybase
run_keybase -k
sudo umount -l /keybase
fusermount -uz /run/user/$(id -u)/keybase/kbfs


# 5. Remove it for good (data is server-side)
sudo dnf remove -y keybase
sudo rm -f /etc/yum.repos.d/keybase.repo
rm -rf ~/.cache/keybase ~/.config/keybase ~/.local/share/keybase ~/.config/Keybase
rm -f ~/.config/autostart/keybase_autostart.desktop
sudo rm -rf /opt/keybase /keybase