Steam client updates can't install if compatibilitytools.d is on a different filesystem (e.g. as symlink)

steamopen Steam client

ValveSoftware/steam-for-linux#11830 · opened 2025-03-17 by Orochimarufan · updated 2026-07-12 · 4 comments · github

OOrochimarufan 2025-03-17 github

Your system information

Steam client version (build number or date): 1731433018
Distribution (e.g. Ubuntu): Flatpak (on Arch)
Opted into Steam client beta?: No
Have you checked for system updates?: Yes (updates don't install though)
Steam Logs: See below
GPU: Intel

Please describe your issue in as much detail as possible:

Steam fails to install client updates when compatibilitytools.d is located (e.g. using a symbolic link) on a different filesystem than the rest of the Steam root. This setup can be useful if a lot of compattools are installed or when developing custom compat tools.

Specifically, it fails to install compatibilitytools.d/LegacyRuntime/compatibilitytool.vdf with POSIX errno 18 (EXDEV), Invalid cross-device link (or in this case, rename):

INFO:root:https://github.com/flathub/com.valvesoftware.Steam/wiki
INFO:root:Will set XDG dirs prefix to /home/taeyeon/.var/app/com.valvesoftware.Steam
DEBUG:root:Checking input devices permissions
INFO:root:Overriding TZ to Europe/Berlin
DEBUG:root:Addding /usr/lib/extensions/vulkan/gamescope/bin to PATH
DEBUG:root:Addding /usr/lib/extensions/vulkan/MangoHud/bin to PATH
steam.sh[2]: Running Steam on org.freedesktop.platform 24.08 64-bit
steam.sh[2]: STEAM_RUNTIME is enabled automatically
setup.sh[48]: Steam runtime environment up-to-date!
steam.sh[2]: Steam client's requirements are satisfied
CProcessEnvironmentManager is ready, 6 preallocated environment variables.
[2025-03-17 23:17:28] Startup - updater built Nov 12 2024 17:09:08
[2025-03-17 23:17:28] Startup - Steam Client launched with: '/home/taeyeon/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/steam' '-srt-logger-opened' '-no-cef-sandbox'
03/17 23:17:28 minidumps folder is set to /tmp/dumps
03/17 23:17:28 Init: Installing breakpad exception handler for appid(steam)/version(1731433018)/tid(94)
[2025-03-17 23:17:28] Loading cached metrics from disk (/home/taeyeon/.var/app/com.valvesoftware.Steam/.local/share/Steam/package/steam_client_metrics.bin)
[2025-03-17 23:17:28] Using the following download hosts for Public, Realm steamglobal
[2025-03-17 23:17:28] 1. https://client-update.fastly.steamstatic.com, /, Realm 'steamglobal', weight was 900, source = 'update_hosts_cached.vdf'
[2025-03-17 23:17:28] 2. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 100, source = 'update_hosts_cached.vdf'
[2025-03-17 23:17:28] 3. https://client-update.steamstatic.com, /, Realm 'steamglobal', weight was 1, source = 'baked in'
[2025-03-17 23:17:28] uninstalled manifest found in /home/taeyeon/.var/app/com.valvesoftware.Steam/.local/share/Steam/package/steam_client_ubuntu12 (1).
[2025-03-17 23:17:28] Found pending update
[2025-03-17 23:17:28] Installing update...
[2025-03-17 23:17:32] Extracting package...                                                                                                                                                   [2025-03-17 23:18:06] Installing update...
[2025-03-17 23:18:06] BCommitUpdatedFiles: failed to rename package/tmp/./compatibilitytools.d/LegacyRuntime/compatibilitytool.vdf_ -> ./compatibilitytools.d/LegacyRuntime/compatibilitytool.vdf (error 18)
[2025-03-17 23:18:06] BCommitUpdatedFiles: failed to process ./compatibilitytools.d/LegacyRuntime
[2025-03-17 23:18:06] BCommitUpdatedFiles: failed to process ./compatibilitytools.d
[2025-03-17 23:18:06] Failed to apply update, reverting...
[2025-03-17 23:18:06] Verifying installation...
[2025-03-17 23:18:07] Verification complete

I'm guessing that the LegacyRuntime compattool was included somewhere around Nov 2024, which has caused my client to stop actually applying updates since then. Removing my compatibilitytools.d symlink allowed steam to update to 1741737356. The updater should probably be able to handle EXDEV gracefully.

Steps for reproducing this issue:

Make ~/.local/share/Steam/compatibilitytools.d (respective ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d) be a symlink to another filesystem
Start Steam with an update available
Steam will try to update itself and silently (unless specifically checking terminal output) fail

Bbenaryorg 2025-06-19 github

Note that this also happens when using btrfs subvolumes (for example to have different backup/snapshot policies for different parts of Steam, such as making backups of savegames and compatibilitytools.d but not Steam itself).
As far as I can tell Steam is trying to somehow hard-link the files instead of actually renaming (or if you really wanna be smart use ioctl(2) with FICLONE(2const) and fall back to renaming).

TTerminalHash 2025-11-10 github

same with another symlinks in steam folder, im tried to change update package location and it's cannot to rename/create/find files.

GGenocideStomper 2026-07-12 github

I might have a similar issue:

I tried symlinking ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d to ~/.local/share/Steam/compatibilitytools.d, however when running Steam I get the error:

$ flatpak run com.valvesoftware.Steam
bwrap: Can't bind mount /oldroot/home/user/.local/share/Steam/compatibilitytools.d on /newroot/home/user/.local/share/Steam/compatibilitytools.d: Unable to mount source on destination: No such file or directory

Flatpak permissions to ~/.local/share/Steam/compatibilitytools.d are given. Symlinking the contents of the directory work.

Bbenaryorg 2026-07-12 github

I might have a similar issue

As far as I can tell the issue you are facing is unrelated.

detailed response to your issue

It looks like you are trying to make the symlink point to a directory outside the sandbox created by Flatpak (i.e. ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d -> ~/.local/share/Steam/compatibilitytools.d).
However this is fundamentally not possible with a symlink; the symlink will remain a symlink inside the sandbox, and thus will be resolved inside the sandbox.
This means your symlink effectively points at its own location, which means Flatpak (or bubblewrap to be precise) will fail to mount anything to that location, since that location by itself does not point at anything.

On the other hand if you try to use a symlink to point the host system's compatibilitytools.d to that of the sandbox (i.e. ~/.local/share/Steam/compatibilitytools.d -> ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d), that should work fine with the caveat that you cannot use Flatpak features to expose that directory then because the host's compatibilitytools.d simply isn't a directory and can't be bind-mounted[^edit-bind] (and even if it worked you'd be bind-mounting it onto itself which isn't particularly useful to begin with).

[^edit-bind]: Edit: technically files can be bind-mounted, but symlinks cannot, as symlinks are generally resolved before being used by the actual mount operation when used as a source. Perhaps there are some more in-depth mechanics when using mount(2) directly, but none of them will achieve what you're trying to achieve. Please also note that ~/.var/app/com.valvesoftware.Steam does exist inside the sandbox.

If you want to expose the hosts compatibilitytools.d to the sandbox, then ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d (i.e. the directory from inside the sandbox) should either not exist or be an empty directory.

This GitHub issue in particular is about Steam failing to operate on the directory during the update process due to internal hard-link mechanics, which in any case would happen after Steam has already started its self-updater (with your issue referencing Flatpak failing to start Steam at an earlier stage).

Nothing extracted yet.