protonscr

Shouldn't allow creating a Steam library in locations that won't work

steamopen Steam clientruntime
ValveSoftware/steam-for-linux#10096 · opened 2023-09-29 by smcv · updated 2025-01-10 · 3 comments · github
Ssmcv 2023-09-29 github

Your system information

  • Steam client version (build number or date): any
  • Distribution (e.g. Ubuntu): any
  • Opted into Steam client beta?: n/a
  • Have you checked for system updates?: n/a
  • Steam Logs: n/a
  • GPU: n/a

Please describe your issue in as much detail as possible:

There are several reserved filesystem paths that can't be used by the Steam Linux Runtime container runtime framework. Increasingly many games being run on Linux are either Windows games via Proton or native Linux games via Steam Linux Runtime 3.0 (sniper), which won't work if Proton, Steam Linux Runtime or the game itself are installed into a library in one of these reserved locations.

The container runtime doesn't have control over its own install location, and doesn't have any user interface other than logging, so it isn't a good place to handle this error. The Steam client should not allow these reserved locations to be used as locations for Steam libraries, with a user-facing error message (or at least a warning).

The affected paths are mainly /etc and /usr/local, but for completeness, none of these should be allowed:

  • /app (non-standardized path, reserved because we recycle code from Flatpak)
  • /bin
  • /boot
  • /dev
  • /etc
  • /lib* (including /lib32, /lib64, /libx32)
  • /overrides (non-standardized path, used internally by the Steam Linux Runtime)
  • /proc
  • /root
  • /sbin
  • /sys
  • /usr (including /usr/local)
  • /var

Most of /run and /var/run also won't work, but there are exceptions to those: /run/flatpak/doc, /run/media and /run/user/*/doc should be OK.

In particular, I expect Steam libraries below /run/media/ to be common, especially on Steam Deck, so Steam definitely does need to allow those.

Steps for reproducing this issue:

For example see https://github.com/ValveSoftware/steam-runtime/issues/621, https://github.com/ValveSoftware/steam-runtime/issues/288.

Llorddevereux 2024-03-14 github

Confirmed this is still an issue, games simply fail silently. There should be some kind of GUI notification as to what went wrong or why.

Ttheandrewbailey 2025-01-09 github

Should Steam even care so much where things are installed? Can Steam just trust that if a Linux user puts something in a certain place that they have their reasons and not error or question it? I've never encountered nor heard of Steam being so picky on Windows (where I've used it for 20+ years).

I just did a fresh install on an older system with / on a hard drive, and /usr on an SSD, thinking 'all my binaries will be on the SSD, and I can put a Steam library in /usr/games so they're fast'. This container framework error (and Steam's inability to use anything other than EXT4/ExFAT) has caused me so much frustration over the past day that I'm not convinced that Steam is ready for prime-time by general Linux users.

Ttheandrewbailey 2025-01-10 github

I used mount --bind as suggested in https://github.com/ValveSoftware/steam-runtime/issues/288. It's a heavy-handed workaround (namely an entry in fstab), but it ends up working how I'd like. Games launch, and Steam even reports the correct amount of free space on the disk where it's at.

Upstream links