Do you have PRESSURE_VESSEL_SHARE_HOME=0 in the environment, or any other special environment variables set?

PRESSURE_VESSEL_SHARE_HOME=0 was an experimental feature that is not actively supported, and it wouldn't surprise me if it breaks the ability to run steamwebhelper now that steamwebhelper is using a container.

It would probably be possible to work around this in the Steam client by unsetting that variable for steamwebhelper, while leaving it set for games.

Removed PRESSURE_VESSEL_SHARE_HOME, nothing changes. I even tried to launch steam in terminal after env -i bash command, with DISPLAY=:0. My envs:
envs.txt

I am having the exact same problem.

Removed PRESSURE_VESSEL_SHARE_HOME, nothing changes.

Are you sure you completely exited and restarted Steam after unsetting that variable?

If you run steam in terminal 1 while a copy of Steam is already running in terminal 2, then the copy in terminal 1 will just send a message to the one in terminal 2, and Steam will continue to run with the same environment variables that it inherited from terminal 2.

Yes i'm sure. I tried to run steam after reboot.

That's strange... there must be something we don't understand yet going on here. If you had used PRESSURE_VESSEL_SHARE_HOME=1 as a local tweak then I would have expected it to trigger this issue, but I wouldn't have expected its effect to persist after unsetting that environment variable.

Should i upload logs without this variable?

Yes, please collect logs with that variable unset, but I suspect they might only tell us what we already know. Running with STEAM_LINUX_RUNTIME_VERBOSE=1 will make them most likely to provide useful information, but I think this error message happens before we get far enough to log very much.

While Steam is in the bad state (steamwebhelper unreachable/restarting in a loop), it would be useful if you can get the process ID of the top-level Steam process (from pstree or systemd-cgls or similar), and then do:

$ grep -z -i -e '^PRESSURE' -e '^STEAM' -e '^SRT' "/proc/$steam_pid/environ" | perl -pe 's/\0/\n/g'

replacing $steam_pid with the process ID of Steam.

Beyond that, probably the only way to get useful information out of this might be if I build a version of pressure-vessel that logs more information about where it got the idea that it should be unsharing $HOME, and ask you to replace the one Steam is using with that.

I even created new user with clean profile with the same results. ... I installed linux on USB-stick (same Arch by the way, "normal" installation not just live-image). Boot up and installed drivers and steam there and steam works just fine.

That does suggest that this is triggered by your OS-level configuration/customization (not your user account or anything in your home directory, because you could reproduce the bug with a new user account; but also not your hardware, because you couldn't reproduce the bug in a fresh installation).

Can you think of any unusual configuration/customization you have done at OS level that might have an impact on Steam?

A temporary workaround is to run Steam with PRESSURE_VESSEL_BATCH=1 in the environment. Ideally this should be enabled for steamwebhelper but not for games, but that will require a Steam client change; until that happens, enabling it for everything (games as well) is relatively harmless. Please remember that you have done this workaround, so that you can undo it after an updated Steam version has been released.

To diagnose why this is happening to you, please download and unpack https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/473743/artifacts/raw/_build/pressure-vessel-bin.tar.gz in some suitable place (let's say $HOME/tmp), and then run Steam as:

PRESSURE_VESSEL_BATCH=1 \
PRESSURE_VESSEL_PREFIX=$HOME/tmp/pressure-vessel \
steam

Then look at ~/.steam/root/logs/steamwebhelper.log. You should find that near the beginning of the log, it says something like:

pressure-vessel-wrap[12345]: N: Unsharing $HOME as a result of PRESSURE_VESSEL_SHARE_HOME=0
pressure-vessel-wrap[12345]: N: Unsharing $HOME in batch mode

(This is a debug build taken from https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/687, which has some extra log messages so that we can figure out what is going on.)

Well. You was right it is variable. It's a different error message now:bwrap: Can't make symlink at /var/run: File exists
And as you suggested here: https://github.com/flatpak/flatpak/issues/5255 i make /media a symlink to /run/media instead of /var/run/media and it works. Thanks.

@wegle030:

I am having the exact same problem.

If you are really having the same problem as @y-salnikov, with the error message E: Either --home, --freedesktop-app-id, --steam-app-id or $SteamAppId is required in your log, please see https://github.com/ValveSoftware/steam-for-linux/issues/10602#issuecomment-1991728893.

If you are seeing the same symptom (steamwebhelper not starting) but without that error message, then it is not the same problem: please report a separate issue with your own logs.

It would probably be possible to work around this in the Steam client by unsetting that variable for steamwebhelper, while leaving it set for games.

... or perhaps better done by explicitly setting it to 1. Tracked as steamrt/tasks#420 internally.

It would probably be possible to work around this in the Steam client by unsetting that variable for steamwebhelper, while leaving it set for games.

... or perhaps better done by explicitly setting it to 1.

This change was committed, and went out in or before Steam beta 1710786209 (2024-03-18).