I run steam inside a Cachyos Podman container and I'm observing case 2. (stuck on waiting for network) as well, had to downgrade to 20260630154056 for it to work again.

The container has no access to system dbus nor user dbus, notably things like NetworkManager is out of steam's reach. I wonder if that has to do with the indefinite waiting for network.

might be related:
https://github.com/ValveSoftware/steam-for-linux/issues/9587
https://github.com/ValveSoftware/steam-for-linux/issues/9966

@RJSent I'm not sure where it would be in your system, but can you check the equivalent of /tmp/dumps for minidumps and attach them to this issue? If you'd like to reduce the number of dumps to attach you can clear out the folder and then repro the crash.

Can you also attach the full stdout of running steam outside a debugger? Normally that is created as a console-linux.txt file, but on your setup that doesn't seem to be working.

I hope this may help other to solve the issue on their computer:
I run Steam in Firejail. And after installing the latest Steam update today (2026-07-25) I had to allow write access to /run/dbus on a computer NOT using NetworkManager. Meanwhile the latest Steam is working WITHOUT /run/dbus access on another computer using NetworkManager.
I don't know the last working Steam version. But I probably updated Steam last some-when in the first 2 July weeks on the affected computer.

both computers:
Steam Version: 1784778118
OS: Debian-13

I can confirm and maybe narrow down this issue for the "stuck on Waiting for network, no crash" variant (i.e. without pipewire/pipewire-pulse running). I'm running StumpWM on GNU Guix as well.

Probable root cause: the Steam container's mount namespace does not include /run/dbus, so DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket (inherited from the host environment) points to a socket path that doesn't exist inside the container. I confirmed this by inspecting the running steamwebhelper process:

$ cat /proc/<pid>/environ | tr '\0' '\n' | grep -i dbus
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

$ ls -la /proc/<pid>/root/run
current-system
user

Note /run/dbus is missing from the container's /run. The steamwebhelper CEF log shows the resulting failure as:

[INFO:CONSOLE(2)] "SteamApp Init - Before Login - SystemNetworkStore - ERROR TypeError: SteamClient.System.Network.RegisterForDeviceChanges is not a function"

SystemNetworkStore tries to register for network-change notifications via the system D-Bus (presumably to talk to NetworkManager), can't reach it, and Steam hangs indefinitely on the network-check splash.

Workaround: explicitly share /run/dbus into the nonguix container:

GUIX_SANDBOX_EXTRA_SHARES=/run/dbus steam

This resolves the hang and lets Steam log in normally for me. My system does not have pipewire/pipewire-pulse installed at all, so I can't speak to the segfault variant reported above, but the "waiting for network" hang specifically looks like a missing D-Bus system bus mount rather than anything audio-related.

I can confirm the GUIX_SANDBOX_EXTRA_SHARES fix resolved the "waiting for network" issue I saw. It did not resolve the Pipewire crash.

@lostgoat re. the Pipewire crash, here's a tarball containing the contents of /tmp/dump, console + gdb output, and a cleaned out Steam/logs folder where I ran Steam once in gdb, then once directly in the console. I also added the home dbus and pipewire-pulse service logs.

steam_pipewire.tar.gz

Edit: Previously restarting pipewire and pipewire-pulseaudio did not resolve the issue, but it did in my most recent attempt. The first part of this issue may be a duplicate of #9289.

Running Steam inside a Portable sandbox and experiencing the same issue.

I would rather not allow system bus access since that may cause unauthorised permission elevation due to poorly written services. Portable at this stage does not have filtering rules for system bus unlike the user bus either.

Here's a hacky workaround without exposing system bus: just set the session bus address as system bus address

https://github.com/Kraftland/portable-arch/pull/129/commits/c668a62426ef2caaa0d8f758375f3407c432f031

Most of these reports (all but the podman report, which surprises me with no dbus at all) seem to point to a change that Steam won't start with just a system dbus anymore. For example, I don't reproduce on nonguix as I do have user dbus which does get shared to the container Steam runs in. This assumes users without a user dbus session previously didn't either (sounds like the case).

I will note that the reports look to be in non-DE setups, meaning the user probably needs to be the one to start a user dbus session. However, I think it is probably more "correct," for lack of a better term, that one should have a user dbus session and that is what Steam should use. See https://dbus.freedesktop.org/doc/dbus-daemon.1.html for instance.

It would help to have confirmation from Steam what is expected, though this might be a case where those on setups besides e.g. Gnome or KDE are expected to make sure they have things like a user dbus session started.

(Edit: Ah, a system dbus session could also be for adding/removing devices, so perhaps Steam should or does require both for full operation? At least right now, just the user session is required to start, while previously it was just any dbus it seems.)

It requires the system bus since that Jul 21st client update. Though a skeleton bus (in my case, it's the sandboxed user bus masqueraded as system bus) is good enough to trick Steam.

I have heard in the past that Steam interfaces with NetworkManager to get connectivity and not granting the TALK permission results in a few seconds timeout delay when logging in, and it also seems to use UPower and Udisks judging from Flatpak's manifest though not granting access doesn't brick the whole client.

Possibly the same underlying bug. On Fedora Asahi Remix 44 (aarch64, Apple M1 Pro, Steam running under FEX-Emu + muvm microVM), a completely clean install (fresh ~/.local/share/Steam, no prior config) reproduces this exact symptom on both stable (1785799196, built Aug 3 2026) and publicbeta (1785347151, built Jul 29 2026).

cef_log.txt shows:

SteamApp Init - Before Login - SystemNetworkStore - ERROR
TypeError: SteamClient.System.Network.RegisterForDeviceChanges is not a function
source: https://steamloopback.host/library.js

This isn't a real network problem — connection_log.txt shows every connectivity test passing (IPv4 OK, IPv6 HTTP SUCCESS, IPv6 UDP SUCCESS), and steamui_login.txt shows the backend reports SetLoginState: WaitingForCredentials - OK. The UI just never advances past "Waiting for network."

I checked whether the function exists in the shipped binaries:

$ strings ~/.local/share/Steam/ubuntu12_64/steamclient.so | grep -c RegisterForDeviceChanges
0
$ strings ~/.local/share/Steam/ubuntu12_64/steamwebhelper | grep -c RegisterForDeviceChanges
0

steamui/chunk~2dcc5aaf7.js calls this function, but it doesn't exist in either steamclient.so or steamwebhelper. I've opened a separate issue with full details: [link once posted]

Reproduces in both desktop UI and Big Picture mode (-gamepadui).

Have you tried enabling SteamRT3 client? That seems to have fixed Steam recognizing NetworkManager for me on Guix, but I had no problem launching it in either case though.

I had this issue on my laptop but not on my desktop, both running Guix. The SteamRT3 client fixed it for me. I had to add /run/dbus to GUIX_SANDBOX_EXTRA_SHARES in order to get it to start to be able to change to SteamRT3, but after that it starts fine without it.

@Bu156 Strange that you needed to share /run/dbus, nonguix steam sandbox should expose /var/run/dbus (which is a symlink to /run/dbus).