They are referred to differently too, my primary drive is listed as "Local Drive (/)" and my other drive "/games". In RT3 my primary drive is list as "/run/host/usr" and the other storage area isn't listed. I can attempt to add the other drive but it does not appear.

Notably external drives are accessible through XDG directories (although I have only actually confirmed that one works). Specifically in my case I have XDG_CACHE_HOME pointing to a directory in an external drive and was able to make a new Steam library in that location. Seems like the container only has access to the standard XDG directories, plus the user's Steam directory.

Seems like the container only has access to the standard XDG directories, plus the user's Steam directory

Yes, that. It's using the same list of shared paths as Steam Linux Runtime (and Proton) games, https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md, which was originally intended to be appropriate for individual games and hasn't yet been adjusted for running the entire Steam client in a container.

The simplest workaround is to not use the experimental steamrt3c-based client yet, if you are relying on a Steam Library elsewhere in the filesystem.

If your other drives were mounted below a FHS path like /home, /media, /mnt, /run/media or /srv, then the new Steam client would probably still be able to see them.

Running Steam with something like PRESSURE_VESSEL_FILESYSTEMS_RW=/games:/storage/games in the environment would probably also be a workaround.

Running Steam with something like PRESSURE_VESSEL_FILESYSTEMS_RW=/games:/storage/games in the environment would probably also be a workaround.

You are absolutely correct, setting this variable makes the libraries work again. I'm just going to put this into my /etc/environment for now.

If your other drives were mounted below a FHS path like /home, /media, /mnt, /run/media or /srv, then the new Steam client would probably still be able to see them.

I can confirm that, for example /mnt/games works fine here.

confirming this issue. i have my steam library on a separate btrfs subvolume, and can't use it in the beta without that env var.

Yeah thanks for the hint, my zfs works now, even if steam doesn't really support COW filesystems, causing a lot of issues. But well better than nothing. (I was hoping at the time for the deck that valve would just use btrfs or zfs subvolumes for the games and do some magic snapshoting magic for different versions and betas but i digress)

You might additionally get some issues with ge-proton etc.: (maybe push this into a separate issue)
bwrap: execvp /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb: Too many levels of symbolic links
It is triggered by the process being spawned, I could trace it to this call:

[pid 44512] execve("/usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb", ["/usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb", "--prefix=/usr/lib/pressure-vessel/from-host", "--generate-locales", "--fd", "18", "--regenerate-ld.so-cache", "/var/pressure-vessel/ldso", "--add-ld.so-path", "/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu", "--add-ld.so-path", "/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu", "--set-ld-library-path", "/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases", "--exit-with-parent", "--subreaper", "--assign-fd=1=5", "--assign-fd=2=6", "--", "/home/user/.local/share/Steam/compatibilitytools.d/GE-Proton9-25/proton", "run", "/home/user/.local/share/Steam/steamrt64/../bin/d3ddriverquery64.exe"], 0x3cb19080 /* 115 vars */) = -1 ELOOP (Too many levels of symbolic links)

That is how I realized it is a bug with the compatibilitytools.d not being mounted right maybe or doubling down on the mount namespace, as in a pressure vessel within a pressure vessel?
and well a lot of file copying as hardlinking is not possible (which is to be expected)
i.e.:

pressure-vessel-wrap[38529]: W: Unable to create hard link "/home/user/.local/share/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/var/tmp-8O12L3/usr/./libexec/steam-runtime-tools-0/i386-linux-gnu/i486/libidentify-platform.so" to "/steam/SteamLibrary/steamapps/common/SteamLinuxRuntime_sniper/sniper_platform_3.0.20260119.200241/files/./libexec/steam-runtime-tools-0/i386-linux-gnu/i486/libidentify-platform.so": Invalid cross-device link

^ this stopped after removing the compatibiltytools.d folder as well. Might be related to that.

bwrap: execvp /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb: Too many levels of symbolic links

This is a separate issue, indicating that Steam is trying to launch something (potentially a custom compatibility tool) in its own container, while already in the steamrt3c container. This is a known problem and not intended: Steam correctly launches each game in its own parallel container, but some code paths for non-games like diagnostic tools etc. aren't doing this correctly yet (very similar to #13006).

This is hopefully fixed in Steam Client beta 1780965181 or later (2026-06-09 or later): custom top-level directories like /games are now shared with the Steam Client container by default.

In RT3 my primary drive is list as "/run/host/usr"

This display issue might not be fixed yet, but it should only be a cosmetic problem now.

I've tested with a current build and works fine now and displays it correctly.

Steam Version: 1781911235

I've tested with a current build and works fine now and displays it correctly

@kisak-valve, we can probably close this issue now? The original reporter didn't confirm the final fix but did previously confirm a workaround, and another Steam user has now confirmed that the fix is working.