Steam client version (build number or date): 1773426488 (Steam Deck Stable, March 12 2026)
Distribution: Bazzite 43.20260415 (bazzite-deck:stable, Fedora Atomic base)
Opted into Steam client beta?: Yes (Steam Deck Stable beta branch)
Have you checked for system updates?: Yes
Steam Logs: Attached — content_log.txt included, incident log lost to rotation
GPU: AMD (Sapphire Nitro+ RX 9070 XT)
Please describe your issue in as much detail as possible:
After logging out of Steam in Desktop Mode, rebooting, and launching into Gaming Mode (bazzite-deck), Steam completely wiped the contents of a secondary EXT4 drive configured as a Steam library (~3TB, including Star Citizen and a full Steam library). Data recovery was attempted using testdisk/photorec but was unsuccessful
Analysis of content_log.txt revealed the following on startup at 2026-04-16 07:01:12:
Install folder /var/mnt/games/SteamLibrary not mounted.
Loaded 4 apps from install folder "/run/media/system/games/SteamLibrary/steamapps"
Triggered async write of Steam library folders configuration (3 libraries).
NotifyAddDrive: re-adding drive folder: /run/media/system/games/SteamLibrary/steamapps
Steam had two conflicting paths for the same library in its config — /var/mnt/games/SteamLibrary (registered but not mounted) and /run/media/system/games/SteamLibrary (the actual automount path assigned by bazzite-deck). This path mismatch is created automatically by bazzite-deck's drive handling, not by user misconfiguration. Steam interpreted the /var/mnt/ path as a failed/missing library and appears to have acted destructively on the library contents as a result. Every subsequent app update entry in the log shows reuse 0/0, confirming zero game files existed on the drive by the time Steam started. The destruction occurred in the ~6.5 hour window between the last CS2 session ending at 2026-04-16 00:33:59 and Steam restarting at 07:01:12.
Expected: Steam should handle a mount path conflict gracefully — warning the user or waiting, never silently destroying library contents.
Related historical bug: ValveSoftware/steam-for-linux#6543
Steps for reproducing this issue:
On bazzite-deck, configure a secondary EXT4 drive as a Steam library (automounted by label, path registers as both /var/mnt/ and /run/media/system/ in Steam's config)
Log out of Steam in Desktop Mode
Reboot and launch into Gaming Mode (bazzite-deck)
Switch to Desktop Mode — secondary drive Steam library contents are completely wiped with no warning or confirmation prompt
Your system information
Steam client version (build number or date): 1773426488 (Steam Deck Stable, March 12 2026)
Distribution: Bazzite 43.20260415 (bazzite-deck:stable, Fedora Atomic base)
Opted into Steam client beta?: Yes (Steam Deck Stable beta branch)
Have you checked for system updates?: Yes
Steam Logs: Attached — content_log.txt included, incident log lost to rotation
GPU: AMD (Sapphire Nitro+ RX 9070 XT)
Please describe your issue in as much detail as possible:
After logging out of Steam in Desktop Mode, rebooting, and launching into Gaming Mode (bazzite-deck), Steam completely wiped the contents of a secondary EXT4 drive configured as a Steam library (~3TB, including Star Citizen and a full Steam library). Data recovery was attempted using testdisk/photorec but was unsuccessful
Analysis of content_log.txt revealed the following on startup at 2026-04-16 07:01:12:
Install folder /var/mnt/games/SteamLibrary not mounted.
Loaded 4 apps from install folder "/run/media/system/games/SteamLibrary/steamapps"
Triggered async write of Steam library folders configuration (3 libraries).
NotifyAddDrive: re-adding drive folder: /run/media/system/games/SteamLibrary/steamapps
Steam had two conflicting paths for the same library in its config — /var/mnt/games/SteamLibrary (registered but not mounted) and /run/media/system/games/SteamLibrary (the actual automount path assigned by bazzite-deck). This path mismatch is created automatically by bazzite-deck's drive handling, not by user misconfiguration. Steam interpreted the /var/mnt/ path as a failed/missing library and appears to have acted destructively on the library contents as a result. Every subsequent app update entry in the log shows reuse 0/0, confirming zero game files existed on the drive by the time Steam started. The destruction occurred in the ~6.5 hour window between the last CS2 session ending at 2026-04-16 00:33:59 and Steam restarting at 07:01:12.
Expected: Steam should handle a mount path conflict gracefully — warning the user or waiting, never silently destroying library contents.
Related historical bug: ValveSoftware/steam-for-linux#6543
Steps for reproducing this issue:
On bazzite-deck, configure a secondary EXT4 drive as a Steam library (automounted by label, path registers as both /var/mnt/ and /run/media/system/ in Steam's config)
Log out of Steam in Desktop Mode
Reboot and launch into Gaming Mode (bazzite-deck)
Switch to Desktop Mode — secondary drive Steam library contents are completely wiped with no warning or confirmation prompt
content_log.txt