Repository navigation
[Bug]: bwrap: Can't find source path /run/user/1000/.flatpak-helper/pkcs11-flatpak-1644: No such file or directory #6341
Description
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.16.1
What Linux distribution are you using?
Arch Linux
Linux distribution version
6.16.8-arch3-1
What architecture are you using?
x86_64
How to reproduce
- Restart computer
- Wait a few hours
- Try to launch any Flatpak application
Expected Behavior
Application should launch properly
Actual Behavior
Application does not launch. When attempting to launch from the terminal, this error is shown: bwrap: Can't find source path /run/user/1000/.flatpak-helper/pkcs11-flatpak-1644: No such file or directory
Additional Information
All applications were working fine until a few days ago. I did both a system update (pacman -Syu) and updated all Flatpak packages (flatpak update).
I'm not sure the exact scenario that triggers it, but I can restart my computer and launch applications just fine. However after some arbitrary amount of time, all Flatpak applications failed to load and I get the error specified error message .
This does not stop already running applications, just prevents new ones from launching.
Activity
melroy89 commentedon May 13, 2026
I also seems to have this. very weird indeed Nheko-Reborn/nheko#2049 (comment)
swick commentedon May 13, 2026
The file should have been created by the session helper. You can mask the session helper and then at least the error should go away. However, it does not fix the real issue. Logs of the session helper would be useful.
ImDevinC commentedon May 15, 2026
@swick is that just
journalctl --user -u flatpak-session-helper.service? If so, I'm not seeing anything of relevance there, just "Starting flatpak session helper" and "Stopping flatpak session helper"melroy89 commentedon May 15, 2026
Same.
Eventually it just auto resolved for me. Without doing anything. But still weird issue.
nickjwhite commentedon May 18, 2026
I just saw exactly the same thing, using Fedora Sway Atomic 44 here. A
systemctl --user restart flatpak-session-helper.servicegot things working again, nothing useful in the logs for it for me, either.weckr commentedon May 31, 2026
fedora sway atomic 43, the helper restart also works
swick commentedon Jun 1, 2026
use
G_MESSAGES_DEBUG=allto get more logsFede654 commentedon Jun 6, 2026
Hitting this on Flatpak 1.16.6 (Debian 13/trixie). The symptom matches exactly — every Flatpak app fails at launch with
bwrap: Can't find source path /run/user/$UID/.flatpak-helper/pkcs11-flatpak-<N>, already-running apps keep working, a reboot fixes it, and after enough uptime it returns. I think I can add a diagnosis and a workaround.The
<N>is the PID of the still-runningflatpak-session-helper. In my case the helper had been alive ~3 days (single start event in the journal, no crash), yet/run/user/$UID/.flatpak-helper/contained onlymonitor/— thepkcs11-flatpak-<N>socket was gone, and the directory's mtime marked a removal time well after the helper started, while it was still running.The source explains why that's unrecoverable without a restart:
start_p11_kit_server()builds the socket once (pkcs11-flatpak-%dwithgetpid()) and spawnsp11-kit serveras a daemon.main(). There's no code that re-checks or recreates the socket if it disappears, and the now-stale path keeps being advertised to every client via thepkcs11-socketD-Bus property inhandle_request_session().So once that socket under
/run/useris deleted out from under the long-lived helper, every later launch bind-mounts a dead path and bwrap aborts.What deletes it: most likely periodic
systemd-tmpfilesage-cleaning of/run/user. There's direct precedent —gvfsd-fuse-tmpfiles.confshipsx /run/user/*/gvfswith the comment "tmpfiles.d defaults are set to clean /run/user every now and then"; gvfs excludes itself for exactly this reason, and the helper's socket has no such exclusion. Honest caveat: I couldn't capture the exact cleanup invocation in my logs (no system-journal access on that box), so this final step is inference rather than proof — but the socket lives in a tmpfs that is known to be age-cleaned, and the "fine after reboot, breaks after uptime" pattern fits.Workaround that has held for me — a tmpfiles exclusion mirroring gvfs's:
Possible real fixes (deferring to maintainers): recreate the socket when it's found missing, ship a tmpfiles exclusion for
.flatpak-helperwith the package, or detect the dead socket and re-spawnp11-kiton demand.Happy to gather more data if it helps triage.
swick commentedon Aug 4, 2026
That sounds reasonable. PR welcome.
smcv commentedon Aug 5, 2026
Whose tmpfiles.d defaults? On my Debian system,
/usr/lib/tmpfiles.d/systemd.confcreates/run/userbut doesn't set an expiry time for it, and that seems to match the latest upstream https://github.com/systemd/systemd/blob/main/tmpfiles.d/systemd.conf.in. The only other reference to/run/userin my/usr/lib/tmpfiles.d/isgvfsd-fuse-tmpfiles.confexcluding its own directory from automatic age-based cleanup, but I don't see anything that actually enables age-based cleanup.Do users affected by this issue have other references to
/run/userin their/usr/lib/tmpfiles.d, perhaps added by the distro or by some other package? It would probably look something like:with a 6th field setting an automatic cleanup time (1 hour, in my example).
@Fede654:
I'm particularly surprised by this, because there doesn't appear to be age-based cleanup configured by default in Debian 13.
session-helper: Lock runtime directory to prevent tmpfiles cleanup
Fede654 commentedon Aug 6, 2026
@smcv I checked my Debian 13 system (Flatpak 1.16.6, systemd 257.13-1~deb13u1) in detail, and ran a live test. You're right to be surprised — there is no age-based cleanup configured for
/run/userhere, and I can now show experimentally thatsystemd-tmpfiles --cleandoes not delete the directory — yet it was deleted.The full effective config (
systemd-tmpfiles --cat-config) contains exactly three references to/run/user:d /run/user 0755 root root -(stocksystemd.conf— no age)x /run/user/*/gvfs(gvfs's own exclusion)x /run/user/*/.flatpak-helperexclusion I added as a workaround after being hit (a no-op given the above)Live test — with my workaround exclusion temporarily removed (i.e. stock Debian 13 config), I ran a real
sudo systemd-tmpfiles --clean:/run/user/1000/.flatpak-helperand its pkcs11 socket survived, and apps still launch. A debug dry-run confirms--cleanonly processesd /run/user(no age → no descent) and the gvfs exclusion. The per-usersystemd-tmpfiles-clean.timer(systemd ≥ 256) is disabled here with no user-level config.Additional data points from my journal for the incident (2026-06-06):
flatpak-session-helper(PID 88546, matching the socket name in the error) was D-Bus-activated on Jun 3 at 11:39.systemd-tmpfiles-clean.servicerun before the failure was Jun 4 at 20:13. I launched no Flatpak apps between that run and the firstbwrap: Can't find source path .../pkcs11-flatpak-88546error on Jun 6 at 19:04, so I can't pinpoint the deletion within that ~47 h window.sudo SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --dry-run --cleantoday reports nothing to remove under/run/user, and the per-usersystemd-tmpfiles-clean.timer(systemd ≥256) is disabled on my system with no user-level config.So at least in my case,
systemd-tmpfilesas configured cannot explain the deletion, and the actual deleter is unknown. Whatever it is, it seems worth noting that the session helper never notices the directory is gone.smcv commentedon Aug 6, 2026
Then it must be something else that is doing this deletion, and #6754 would protect us from a potential future issue (the
systemd-tmpfilescleanup that you speculated about) but is not actually going to solve whatever problem you are encountering.That's normal. If a process has a file or directory open, and the file or directory is unlinked, it disappears from the filesystem but isn't actually deleted: it will only be deleted when the process exits. And, the process would have to go out of its way to notice the deletion.
Monitoring
$XDG_RUNTIME_DIRfor deletions would not be a good solution to this; the good solution to this would be to find whatever is deleting the socket, and make it not do that. But at the moment nobody knows what is deleting the socket on affected systems. Is there some other well-intentioned cleanup going on, liketmpreaperor whatever?(If you're using a LLM to write replies to this issue, please fact-check its output carefully.)
session-helper: Lock runtime directory to prevent tmpfiles cleanup
session-helper: Lock runtime directory to prevent tmpfiles cleanup
session-helper: Lock runtime directory to prevent tmpfiles cleanup
session-helper: Lock runtime directory to prevent tmpfiles cleanup
smcv commentedon Aug 7, 2026
Unfortunately, this is still the case. We briefly thought it might be
tmpfiles.d(systemd-tmpfiles), and #6754 hardens Flatpak against that; but it seems like on at least some of the affected systems, that isn't what is deleting the socket.Probably the best place to start looking, on an affected system, would be anything described as "cleaning up temporary files" or "cleaning up unused files" or similar phrasing, for example
tmpfiles.dortmpreaper, especially if its configuration mentions/run/useror$XDG_RUNTIME_DIR. The most likely reason for this socket to disappear would be if a tool in that category has been misconfigured.The system log (systemd Journal) might also provide useful information. The part of the system log to inspect would be between the last time a Flatpak app launched successfully, and the first time a Flatpak app failed to launch with this error message.
Fede654 commentedon Aug 10, 2026
I did both of these on my affected system (Debian 13, Flatpak 1.16.6). Cleanup tooling:
tmpreaperand similar are not installed, nothing in cron or systemd timers references/run/useror$XDG_RUNTIME_DIR, and the per-usersystemd-tmpfiles-clean.timeris disabled. Journal: my last successful launch was 2026-06-04 and the first failure 2026-06-06 19:04; in that window there is exactly onesystemd-tmpfiles-cleanrun (which, per my earlier test, does not touch the directory), no OOM kills, no package changes, and no cleanup activity of any kind.But re-examining the incident, I don't think an external deleter is needed, and I can reproduce the exact failure another way.
The error in my incident named only the pkcs11 socket —
.flatpak-helper/monitorwas still present. (If the whole directory had been removed, bwrap would have failed on themonitorbind first; I verified this by moving the directory aside.) So only the socket was gone — which also means the new flock-based hardening from #6754 wouldn't have helped in my case, since nothing recursed into the directory.That socket is owned by the
p11-kit serverchild thatflatpak-session-helperspawns. On my system that process daemonizes and reparents tosystemd --user, so the helper cannot notice if it dies — and when it exits on a catchable signal, it unlinks its socket. Test on my live system:kill -TERM <p11-kit-server pid>→ socket disappears,monitorremainsflatpak run→bwrap: Can't find source path /run/user/1000/.flatpak-helper/pkcs11-flatpak-12197: No such file or directory— identical in shape to the original incidentsystemctl --user restart flatpak-session-helperrecoversWhat killed the p11-kit server on 2026-06-06 I can't determine retroactively — it logs nothing. For what it's worth, the failure surfaced ~20 minutes after a resume from suspend, during a period when I was actively reconfiguring lid/suspend handling on this laptop and had previously observed flaky suspend behavior — but the same p11-kit process had survived well over a hundred suspend cycles before that, so I treat this as context, not cause.