I just discovered https://github.com/ValveSoftware/steam-for-linux/issues/13007 which is similar to this, but not identical. That bug is about steam libraries not being writable, mine is about steam libraries being ignored because they're falsely detected as "not mounted".

They have the same workaround, though. I added the following line to the script I used to start steam, and my libraries started working correctly again:

export PRESSURE_VESSEL_FILESYSTEMS_RW=/var/games/steam/steam:/var/games/steam1:/var/games/steam2:/var/games/ssd:/var/games/ssd-linux

NOTE: this is similar to 13007 but not a dupe (although it might have a similar or related cause), nor is it fixed. I've just found a workaround for the bug....which still needs to be fixed.

This should work generically for anyone with a similar problem, rather than being hard-coded to my steam libs:

export PRESSURE_VESSEL_FILESYSTEMS_RW=$(
  perl -lane '
    if (m/"path"/) {
      $F[1] =~ s/"//g;
      push @steamlibs, $F[1]
    };
    END {
      print join(":", @steamlibs)
    }' ~/.steam/steam/config/libraryfolders.vdf
  )

It uses perl to extract the library paths from libraryfolders.vdf and prints them in a : separated format. It wouldn't be hard to rewrite in awk or python or maybe even sed if you suffer from perl-phobia.

I just discovered [#13007](https://github.com/ValveSoftware/steam-for-linux/issues/13007) which is similar to this, but not identical. That bug is about steam libraries not being writable, mine is about steam libraries being ignored because they're falsely detected as "not mounted".

It's basically the same situation, even though the symptom is not the same. Inside the container that the Steam Client now runs in, it is genuinely true that this location is not mounted, because /var/games is not on the list of shared paths for the container framework, so by default it isn't visible inside the container.

If your library partitions/datasets were mounted below a path that is normally shared, like /mnt, /srv, /media, /home or even /opt, then they would work normally.

In principle /var/games could be added to the list of shared paths, but as far as I'm aware it's mostly used by games that are packaged in Linux distributions and are using a separate system-level user ID (for example openarena-server in Debian) or a setgid executable to guard access to state that is shared between all users (for example nethack in Debian), so that might not be the most appropriate location to be storing Steam Library folders belonging to an ordinary user.

The containerized Steam Client does technically have access to the whole host filesystem (/run/host/root inside the container has the same contents as / outside), but it doesn't currently know to access a non-shared location like /var/games/steam1 as /run/host/root/var/games/steam1. I don't know whether the Steam Client team plan to add that functionality.

It's basically the same situation, even though the symptom is not the same

The difference between #13007 and this issue is that in #13007, the reporter had their Steam Library in a custom top-level location with no particular purpose documented in things like the FHS (/games or something), whereas in this issue, you have your Steam Library in a custom location that does have a specific purpose (below /var, and specifically /var/games). The container framework has to be more careful with /var than with unknown top-level directories, because various libraries and tools hard-code paths below /var, and in the container those locations will need to match the container's /etc and /usr, not the host's.