Runtime does not make KIO fuse paths accessible

[VasilisThePikachu]

Your system information

• Steam Runtime Version: 0.20250718.0+srt1
• Distribution (e.g. Ubuntu 18.04): EndeavourOS Linux 6.16.7-1-cachyos
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: https://gist.github.com/VasilisThePikachu/edee9aa88ece462bd6ffa2750b2f973f
• Have you checked for system updates?: YES
• What compatibility tool are you using?: Sniper
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   0.20240806.0                    # Overall version number
LD_LIBRARY_PATH -       scout   -       # see ~/.steam/root/ubuntu12_32/steam-runtime/version.txt
scripts 0.20240806.0                    # from steam-runtime-tools

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   2.0.20250826.159137                     # Overall version number
pressure-vessel 0.20250820.0    scout           # pressure-vessel-bin.tar.gz
scripts 0.20250820.0                    # from steam-runtime-tools
soldier 2.0.20250826.159137     soldier 2.0.20250826.159137     # soldier_platform_2.0.20250826.159137/

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   3.0.20250826.159138                     # Overall version number
pressure-vessel 0.20250820.0    scout           # pressure-vessel-bin.tar.gz
scripts 0.20250820.0                    # from steam-runtime-tools
sniper  3.0.20250826.159138     sniper  3.0.20250826.159138     # sniper_platform_3.0.20250826.159138/

Please describe your issue in as much detail as possible:

Mounts made with KIO fuse (Such as network mounts using KDE's Dolphin) are unavailable inside Sniper, while the file picker will be able to see them, games will complain about inaccessible files when trying to pick and load them.

Using nsenter to go inside the sniper namespace of the running game shows that /run/user/1000/kio-fuse-##### is not mounted within, which explains the error.

In this case, the game I was testing was Space Station 14 and trying to play midi files from a network share. But while it is visible within the dolphin file picker screen, the game is unable to read the file as the path is not actually available.

Steps for reproducing this issue:

1. Install dolphin (KDE's default file manager)
2. Create a network mount via the network tab (type does not matter)
3. Run a game with sniper (The game needs to have file picker support.)
4. Within the game try to pick a file within the network share
5. The game should complain about being unable to find the file/part of the path

[smcv]

Please see https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md.

/run/user/kio-fuse-#####

Really that path? I would have expected something more like /run/user/1000/kio-fuse-something, replacing 1000 by your numeric user ID (the output of the command id -u).

Is the part you have replaced by ##### something constant (like maybe your login name or your numeric user ID) or does it vary between reboots?

If the path used is predictable, then you can tell pressure-vessel to make it available to games by setting the game's Launch Options to something like:

PRESSURE_VESSEL_FILESYSTEMS_RW=/run/user/$(id -u)/kio-fuse-$(id -nu) %command%

[PJB3005]

Really that path? I would have expected something more like /run/user/1000/kio-fuse-something, replacing 1000 by your numeric user ID (the output of the command id -u).

They typo'd, it is indeed under /run/user/<uid>/kio-fuse-####.

Is the part you have replaced by ##### something constant (like maybe your login name or your numeric user ID) or does it vary between reboots?

Not on Linux so I can't test. I do expect it to be a different value per mount though, as the remote contents are mounted immediately in there.

[VasilisThePikachu]

Please see gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md.

/run/user/kio-fuse-#####

Really that path? I would have expected something more like /run/user/1000/kio-fuse-something, replacing 1000 by your numeric user ID (the output of the command id -u).

Apologies, i typod. I updated the original issue.

Is the part you have replaced by ##### something constant (like maybe your login name or your numeric user ID) or does it vary between reboots?

If the path used is predictable, then you can tell pressure-vessel to make it available to games by setting the game's Launch Options to something like:

PRESSURE_VESSEL_FILESYSTEMS_RW=/run/user/$(id -u)/kio-fuse-$(id -nu) %command%

It is different on each mount.

You can see the old mount name from when I made this issue in my terminals history and new mount under my terminals autocompletion.

I was told about the pressure-vessel option (And it does work if you set it up) but due to the unpredictability by KIO fuse It's not really a reliable strategy (It's not even made available under a mount until a program tries to access something from within the directory. So you would either need to figure out how to make it mount to the filesystem before setting the envvar or try to make the game use the mount so it gets created, then set the envvar and then try again.)

[smcv]

That looks like a mktemp-style random filename, which pressure-vessel is not going to be able to predict.

I don't see a way to solve this without bind-mounting all of $XDG_RUNTIME_DIR, which I think we don't want to do, because some of it is likely to be specific to the host system environment and inappropriate/inapplicable for the container.

[smcv]

Run a game with sniper (The game needs to have file picker support.)

What specific mechanism is this game using to have "file picker support"? Do you know what APIs it is calling into?

[VasilisThePikachu]

I think our file picker works via SDL3

[PJB3005]

What specific mechanism is this game using to have "file picker support"? Do you know what APIs it is calling into?

We're currently using SDL3's new filesystem picker API, ShowFileDialogWithProperties, shipping our own SDL3 build (I could definitely use the one from Steam Linux Runtime instead if need be).

[PJB3005]

I think our file picker works via SDL3, if im correct this is the code responsible in our engine https://github.com/space-wizards/RobustToolbox/blob/f75ce13f007550f3dca725b5061d6f2a863f7426/Robust.Client/UserInterface/FileDialogManager.cs#L21

That code's mostly the only nfd/kdialog backends, the actual SDL3 code¹ is here: https://github.com/space-wizards/RobustToolbox/blob/f75ce13f007550f3dca725b5061d6f2a863f7426/Robust.Client/Graphics/Clyde/Windowing/Sdl3.FileDialog.cs

Footnotes

1. Bleeding edge copy of the game uses it, right now the game available on Steam still uses GLFW instead of SDL3, but it can be enabled via config variable. ↩

[sowelipililimute]

What specific mechanism is this game using to have "file picker support"? Do you know what APIs it is calling into?

Robust Toolbox calls into SDL3, which calls into the XDG desktop portal, which (for the reporter) calls into the KDE desktop portal backend, which redirects any e.g. network shares into FUSE mounts if the user selects them. For the non-Flatpak case, XDP is unaware of the Pressure Vessel sandbox for an application, so the path is returned verbatim. For the Flatpak case, it handles exposing them through its Documents portal & own FUSE mount.

This issue shouldn't be reproducible running under Flatpak. For the non-Flatpak case to be fixed, you'd more or less need to support xdg-desktop-portal in a similar manner to what Flatpak or Snap do.

[smcv]

I think GNOME's GVFS would have a similar issue, except in GVFS it's easier to work around and would be more feasible to address in pressure-vessel, because the mount point is always $XDG_RUNTIME_DIR/gvfs (and not a random string like $XDG_RUNTIME_DIR/gvfs-XXXXXX which would be a closer equivalent of what KIO does).

[smcv]

For the non-Flatpak case to be fixed, you'd more or less need to support xdg-desktop-portal in a similar manner to what Flatpak or Snap do

Flatpak and Snap don't really support xdg-desktop-portal: it's the other way around, xdg-desktop-portal supports Flatpak and Snap.

[smcv]

the Pressure Vessel sandbox

Just to avoid misinformation: pressure-vessel sets up a container, but not a sandbox. It is intentionally not a security boundary, and apps that run in the pressure-vessel container are just as privileged as apps that don't (in particular, they have unrestricted access to the D-Bus session bus, and arbitrary code execution outside the container). The container is only for compatibility/predictability, not for security.