I don't remember it ever happened before steamwebhelper was wrapped inside Sniper Runtime's container

This would most likely already have happened if you tried to launch Counter-Strike 2, Dota 2, Endless Sky, Retroarch or any game that runs via Proton, just not Steam itself.

This is probably not going to be straightforward to avoid in bubblewrap, because bubblewrap is a very constrained environment, and it can't make many assumptions about what is or isn't a security vulnerability - so if something fails, it usually has to assume "this could be bad, better to just fail" instead of carrying on regardless.

If you add nosuid,nodev to the device's mount options (which is probably a good idea for a removable device anyway), then that would probably avoid this, by removing the need for it to be remounted. Please try that?

Or, a workaround would be to use noauto,user instead of nofail,x-systemd.automount on your fstab entry for this device, and use your file manager to mount it if and only if it's actually attached.

@kisak-valve, please could you retitle this to mention automounts? That's the key fact here. "... when an automounted partition is unavailable" perhaps.

Just to clarify the scope of the issue, just having the automount configured and unavailable does not seem to be enough to trigger the issue, it is necessary that something is also trying to access the mount point. At least with a recent systemd.

I set up the test case as shown in the OP description:

$ sudo sh -c 'echo "UUID=1d023367-43fc-48ba-813f-cfbbb40e641c /mnt/hdd_gry  ext4 defaults,noatime,nofail,inode_readahead_blks=64,nobarrier,x-systemd.automount    0  1" >> /etc/fstab'
$ sudo systemctl daemon-reload
$ sudo systemctl restart mnt-hdd_gry.automount

And the Steam client could start just fine on my system.

To trigger the issue I had to access the mount point in another terminal with something like:

$ while true; do ls /mnt/hdd_gry/; done

Only while the command above was running the Steam client would fail to start with the following error:

steam.sh[17707]: Log already open
steam-runtime-check-requirements[17853]: W: Child process killed by signal 15: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/mnt/hdd_gry": No such device

steam.sh[17707]: Error: Steam now requires user namespaces to be enabled.

I guess this can happen on a desktop system if some backup daemon, or a filesystem tracker, or a file manager, is accessing the affected mount point.

https://github.com/containers/bubblewrap/issues/653 will help to address those cases.

In Steam Client beta 1780965181 or later (2026-06-09 or later), there is a workaround available for this: if you run Steam with the environment variable PRESSURE_VESSEL_WORKAROUNDS=limit-shared-dirs, it will disable automatic sharing of various top-level directories like /mnt and /srv with the Steam Client's container, and this can be used to work around automount points for unreachable network services or detached external drives.

If you were relying on a top-level directory like /mnt or /srv being shared with the Steam Client because it contains your games library, then you'll need to combine this workaround with PRESSURE_VESSEL_FILESYSTEMS_RW to share any directories that are necessary. For example, if you have games installed in /games and /mnt/local-drive as well as in your home directory, you could use:

env PRESSURE_VESSEL_WORKAROUNDS=limit-shared-dirs \
    PRESSURE_VESSEL_FILESYSTEMS_RW=/games:/mnt/local-drive \
      steam

Further work is still ongoing to use the option added for https://github.com/containers/bubblewrap/issues/653 to help to work around this automatically, but it's likely that the Steam Client will still take a long time to start up on systems that have a non-functioning automount point, and we probably cannot solve that. This sort of error behaviour is a general issue with using automounting for drives that are not always available, and I'd recommend avoiding this use of automounting if possible: having pieces of your filesystem that block for tens of seconds when accessed will tend to hurt performance and robustness, especially for anything that makes use of containers (like the Steam Client and Flatpak).

In Steam Client beta 1780965181 or later (2026-06-09 or later), there is a workaround available for this: if you run Steam with the environment variable PRESSURE_VESSEL_WORKAROUNDS=limit-shared-dirs, [see previous comment for more details]

This workaround is now also available in general availability (non-beta) Steam Client releases. The same workaround is now also available when launching games:

• For games that run under Steam Linux Runtime 3.0 or SLR 4.0 (newer native Linux games, and Proton 8 or later) you should only need to set the environment variables.

• For games that run under SLR 1.0 (older native Linux games) or SLR 2.0 (old versions of Proton), this workaround currently also requires opting in to the beta branch of SLR 2.0. The next update for SLR 2.0 will probably promote this beta to stable.

Further work is still ongoing to use the option added for containers/bubblewrap#653 to help to work around this automatically

This is likely to be in a future beta release of all of the various components.

but it's likely that the Steam Client will still take a long time to start up on systems that have a non-functioning automount point, and we probably cannot solve that

Tests indicate that a non-functioning automount will make Steam take about 5 minutes to start, and games will take about 90 seconds. This comes from the OS rather than the container runtime framework, and doesn't appear to be solvable. The PRESSURE_VESSEL_WORKAROUNDS=limit-shared-dirs workaround will avoid these delays.

This sort of error behaviour is a general issue with using automounting for drives that are not always available, and I'd recommend avoiding this use of automounting if possible

This is still true.

Further work is still ongoing to use the option added for containers/bubblewrap#653 to help to work around this automatically

This is now in the Steam Client public beta, and the public beta branches of Steam Linux Runtime 2.0, 3.0, 4.0. That'll change the failure mode from "container startup fails" to "container startup is very slow, but eventually succeeds".

The workaround described in https://github.com/ValveSoftware/steam-for-linux/issues/10571#issuecomment-4778839026 would speed this up, at the cost of not automatically making all top-level directories available to games and the Steam Client.