ValveSoftware
Can't start container when automounts exist, with misleading error message about userns
Your system information
- Steam client version (build number): 1751405894
- Distribution: Gentoo Linux x86_64 23.0
- Opted into Steam client beta?: Yes/No
- Have you checked for system updates?: Yes
- Steam Logs: steam-logs.tar.gz
- GPU: NVIDIA GeForce RTX 3080 Ti
Please describe your issue in as much detail as possible:
After some update to Plasma, the desktop seems to launch much faster and earlier. It looks like the network is not fully initialized, thus NFS automounts fail to mount if apps try to access it early. Steam's bwrap most likely trips over this:
# systemctl --user status app-steam\\[email protected]
● app-steam\[email protected] - Steam Autostart
Loaded: loaded (/home/kakra/.config/autostart/steam-silent.desktop; generated)
Active: active (running) since Sat 2025-07-05 13:58:38 CEST; 8min ago
Invocation: 7841310b1c754a10a0c4be1e758e0334
Docs: man:systemd-xdg-autostart-generator(8)
Main PID: 4722 (bash)
Tasks: 14 (limit: 37865)
CPU: 3.173s
CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/app-steam\[email protected]
├─4722 bash /home/kakra/.local/share/Steam/steam.sh -srt-logger-opened -no-cef-sandbox -silent
├─4780 /home/kakra/.local/share/Steam/ubuntu12_32/steam-runtime/usr/libexec/steam-runtime-tools-0/srt-logger --sh-syntax --rotate=8388608 --log-directory /home/kakra/.local/share/Steam/logs --filename console-linux.txt --log-fd=7 --j>
└─5131 /bin/zenity --error "--text=Steam now requires user namespaces to be enabled.\n\nThis requirement is the same as for Flatpak, which has more detailed\ninformation available:\nhttps://github.com/flatpak/flatpak/wiki/User-namesp>
Jul 05 13:58:38 jupiter steam-runtime-steam-remote[4747]: steam-runtime-steam-remote: Steam is not running: No such device or address
Jul 05 13:58:38 jupiter steam[4780]: steam.sh[4722]: Running Steam on gentoo 13.0 64-bit
Jul 05 13:58:38 jupiter steam[4780]: steam.sh[4722]: STEAM_RUNTIME is enabled by the user
Jul 05 13:58:38 jupiter steam[4780]: setup.sh[4835]: Steam runtime environment up-to-date!
Jul 05 13:58:44 jupiter steam[4780]: steam.sh[4722]: Log already open
Jul 05 13:58:45 jupiter steam[4780]: steam-runtime-check-requirements[5043]: W: Child process exited with code 1: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/srv/laniakea/git": Operation not perm>
Jul 05 13:58:45 jupiter steam[4780]: steam.sh[4722]: Error: Steam now requires user namespaces to be enabled.
Jul 05 13:58:45 jupiter steam[4780]: This requirement is the same as for Flatpak, which has more detailed
Jul 05 13:58:45 jupiter steam[4780]: information available:
Jul 05 13:58:45 jupiter steam[4780]: https://github.com/flatpak/flatpak/wiki/User-namespace-requirements
The following prominent message is shown on the desktop:
Just clicking "OK" and running the Steam client again successfully launches it.
I think Steam should wait for network being available before working with NFS mountpoints - or maybe ignore them (although some users may need access to NFS mounts from within games).
At the very least, the error message is just wrong and misleading. The client doesn't properly detect the real error.
Steps for reproducing this issue:
- Setup NFS mounts (via systemd automounts)
- Configure the desktop for autologin
- Configure Steam to autolaunch in KDE Plasma
- Reboot
Additional information
# grep nfs /etc/fstab
laniakea-nfs:/volume1/backups /srv/laniakea/backups nfs noauto,noatime,x-systemd.automount,nfsvers=4,x-systemd.idle-timeout=3600
laniakea-nfs:/volume1/casync /srv/laniakea/casync nfs noauto,noatime,x-systemd.automount,nfsvers=4,x-systemd.idle-timeout=3600
laniakea-nfs:/volume1/git /srv/laniakea/git nfs noauto,noatime,x-systemd.automount,nfsvers=4,x-systemd.idle-timeout=3600
laniakea-nfs:/volume1/video /srv/laniakea/video nfs noauto,noatime,x-systemd.automount,nfsvers=4,x-systemd.idle-timeout=3600
laniakea-nfs:/volume1/music /srv/laniakea/music nfs noauto,noatime,x-systemd.automount,nfsvers=4,x-systemd.idle-timeout=3600
My system does not use NetworkManager because it slows down boot considerably for me.
Jul 05 13:58:45 jupiter steam[4780]: steam-runtime-check-requirements[5043]: W: Child process exited with code 1: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/srv/laniakea/git": Operation not perm>
I assume there would be an "Operation not permitted" here if you look at the non-truncated log.
The error message is oversimplifying because it can't reliably tell the difference between "bwrap failed to run because user namespaces are disabled" (the most common reason) and "bwrap failed to run for some unrelated reason"; but either way, none of what Steam does with containers is going to work here, because bwrap doesn't have permission to do some of what it needs to do (locally remount mount points as nosuid,nodev). I assume this would work on NFS mounts if the NFS mount was active (really mounted), but does not work on an inactive automount?
https://github.com/containers/bubblewrap/issues/653 would likely avoid this.
@kisak-valve please could you retitle this to something along the lines of "can't start container when automounts exist, with misleading error message about userns"? The interaction with automounts is the main problem here, and misleading error message is secondary.
I think Steam should wait for network being available before working with NFS mountpoints - or maybe ignore them
At the point in its startup at which compatibility with the container framework is checked, Steam doesn't yet know whether the network is available, whether automounts exist, or whether they are going to get mounted any time soon. The command that it's testing is something along the lines of bwrap --bind / / true, which has no idea whether Steam is going to interact with /srv.
I assume this would work on NFS mounts if the NFS mount was active (really mounted), but does not work on an inactive automount?
"running the Steam client again successfully launches it" suggests that the answer is yes: real NFS mount points can be remounted nosuid,nodev, but automount points acting as a placeholder for where NFS might appear later cannot be remounted.