Misleading "Steam now requires user namespaces" error when bwrap fails on a stale systemd automount mount

[r2-lee]

Environment

• Arch Linux rolling, kernel 7.1.8-arch1-3
• steam 1.0.0.87-1 (native package)
• KDE Plasma 6.7, Wayland
• GPU: AMD RX 7900 XT (amdgpu)

Symptom

Launching Steam fails immediately with:

Error: Steam now requires user namespaces to be enabled.
This requirement is the same as for Flatpak...

However, user namespaces are enabled and working on this system:

• /proc/sys/user/max_user_namespaces = 62287
• unshare -Ur succeeds as a regular user

Actual root cause

steam-runtime-check-requirements fails because bwrap cannot replicate
a stale systemd automount mount point:
steam-runtime-check-requirements[3859]: W: Child process killed by signal 15: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/mnt/win-c": No such device

Context: this is a moving SSD installation. /etc/fstab contains an
x-systemd.automount entry for an NTFS partition that exists on another
machine but not on this one. systemd still creates the autofs mount point;
when the backing device is absent the mount is dead, and bwrap aborts while
building its mount table — which the requirements check then misreports as
"user namespaces not enabled".

Removing the automount entry (or cleaning up the stale mount point) makes
Steam start normally, with no other changes.

Suggestion

When bwrap fails for reasons other than a genuine userns problem,
steam-runtime-check-requirements should surface the underlying bwrap
error instead of concluding that user namespaces are disabled. A hint like
"check for stale/FUSE/network mount points in your mount table" would have
saved hours of debugging.

[smcv]

Error: Steam now requires user namespaces to be enabled

This is the generic message that appears if steam-runtime-check-requirements can't detect the specifics of what is wrong, so it isn't really feasible for it to provide specific information. User namespaces not being enabled were historically the most common reason for this not to work, so it's as good a guess as any other.

The error message can't list all the possible things that could go wrong without becoming unreadably long.

when the backing device is absent the mount is dead, and bwrap aborts while building its mount table

After the next bubblewrap release happens, I'm hoping that improvements made in bubblewrap will mean that a dead automount point will no longer affect container startup.

[smcv]

In fact this should already work more gracefully than it used to in at least the Steam Client beta (perhaps also the stable/GA version) as a result of changes made for #766 and ValveSoftware/steam-for-linux#10571. Steam startup will still be slower than usual on a system with a dead automount point, but it should now work.

Since then there have been additional bubblewrap improvements, which haven't arrived in Steam yet (tracked as steamrt/tasks#1006 internally). When those land, they should also remove the startup time penalty for a dead automount point - I tested a preliminary version today and it does work.