steamwebhelper: bwrap: Can't make symlink at /var/lib/dbus/machine-id: destination exists and is not a symlink

[Panda-Code-Master]

Your system information

• Steam client version (build number or date):
• Distribution (e.g. Ubuntu): Debian
• Opted into Steam client beta?: [Yes/No] No
• Have you checked for system updates?: [Yes/No] Yes
• Steam Logs: steam-logs.tar.gz
• GPU: Nvidia/Intel/AMD : AMD Lucienne [Integrated]

Steps for reproducing this issue:

1. Download latest steam deb / install using steam-installer from apt
2. launch steam
3. get error for steam webhelper always crashing

[Panda-Code-Master]

even after purging all steam files with rm -rf .steam* and reinstalling it still gives the error steamwebhelper, a critical Steam component, is not responding. The Steam UI will not be usable. Click here for more information.

the only workaround / fix to this was using this command steam -forcesteamupdate -forcepackagedownload -overridepackageurl https://web.archive.org/web/20240210115543if_/http://media.steampowered.com/client -exitsteam by which it reverts steam to an older version found from this https://github.com/ValveSoftware/steam-for-linux/issues/9851#issuecomment-1689968393

[kisak-valve]

Hello @Panda-Code-Master, bwrap: Can't make symlink at /var/lib/dbus/machine-id: destination exists and is not a symlink looks like a possible line of interest from your webhelper-linux.txt log.

[Panda-Code-Master]

Hello @Panda-Code-Master, bwrap: Can't make symlink at /var/lib/dbus/machine-id: destination exists and is not a symlink looks like a possible line of interest from your webhelper-linux.txt log.

this error doesn't appear when using the work around https://github.com/ValveSoftware/steam-runtime/issues/688

only in the latest version of steam

[smcv]

This looks like a Steam Linux Runtime issue (@kisak-valve, you could move it to https://github.com/ValveSoftware/steam-runtime/ if you want).

@Panda-Code-Master, we will need more information to be able to solve this. Please try running the updated version of Steam (the one that doesn't work) as:

STEAM_LINUX_RUNTIME_VERBOSE=1 steam

Let it try to start the steamwebhelper for a while (for instance wait until the error dialog pops up), then provide your ~/.steam/steam/logs/webhelper-linux.txt as a Gist or attachment. It will contain environment variables, so if you have any environment variables with secret content (GITHUB_TOKEN or similar), please censor them by replacing their values with a placeholder like xxxx.

I was unable to reproduce the issue with either of the common configurations for /var/lib/dbus/machine-id (either a copy of /etc/machine-id, or a symlink to /etc/machine-id).

[Panda-Code-Master]

Replying to https://github.com/ValveSoftware/steam-runtime/issues/688#issuecomment-2273471562

i did as told with STEAM_LINUX_RUNTIME_VERBOSE=1 steam here is the new logs steam-logs.tar.gz

[smcv]

Here's the culprit:

pressure-vessel-wrap[44395]: D: 'XDG_DATA_DIRS=/home/pranav/.local/share/flatpak/exports/share:/var/lib/:/var/local:/usr/local/share/:/usr/share/:/var/lib/flatpak/exports/share'

This will make pressure-vessel try to make the host system's /var/lib and /var/local available inside the container, but then when it's time to set up /var/lib/dbus/machine-id, it can't do that. We should make the container runtime more robust against this, by making it refuse to do things that won't work.

Workaround: run Steam with /var/lib (and probably also /var/local) removed from your XDG_DATA_DIRS.

Why are those two directories in your XDG_DATA_DIRS to begin with? This is not a typical configuration for Debian.

[Panda-Code-Master]

https://github.com/ValveSoftware/steam-runtime/issues/688#issuecomment-2273942307 i tried that work around and it worked as for why it was there was it was required for flatpak to load desktop entries i think i had done it improperly

[smcv]

Having /var/lib/flatpak/exports/share as an item in your XDG_DATA_DIRS is necessary for Flatpak users. It shouldn't trigger this issue, as far as I know.

Having /var/lib as an item in your XDG_DATA_DIRS is unusual, and that's what's triggering this issue. This shouldn't be necessary to make .desktop files load, unless you have /var/lib/applications/*.desktop?

[smcv]

We should make the container runtime more robust against this, by making it refuse to do things that won't work

This is in progress, and will hopefully be part of a future beta.