Getting Rid of the Snap Steam Client on Linux

The Problem With Snap and Steam

If you installed Steam on Ubuntu by clicking through the Software Center, or typed sudo snap install steam in a terminal, you are running Canonical's Snap-packaged version of Steam. And if your games have been crashing, refusing to launch, or behaving strangely, that packaging decision is likely a significant contributing factor.

This is not speculation. On January 17, 2024, Timothee "TTimo" Besset, a software engineer who does contract work for Valve on the Steam Linux client, posted a clear statement to Mastodon that has since become a frequently cited reference in the Linux gaming community:

Writing on Mastodon, Besset explained that Valve was tracking a rising volume of bug reports originating from Canonical's Snap repackaging -- work Valve has no involvement with. He stated that the snap package "has a lot of issues" and directed users on Debian-based systems to the official .deb at repo.steampowered.com, or at minimum the Flatpak version as an alternative.

-- Timothee "TTimo" Besset, software engineer (contract, Valve), Mastodon, January 17, 2024 (mastodon.social/@TTimo, coverage: GamingOnLinux)

This statement came from someone actively working on Steam's Linux compatibility. Valve's bug queue was filling up with reports that traced back not to their own code, but to how Canonical had wrapped it. In a follow-up response on Mastodon the same week, Besset also noted that if the problem worsened, Valve could consider adding a warning dialog to Steam for users detected to be running the Snap version. As of April 2026, no such warning has shipped. (OMG! Ubuntu, January 2024)

Understanding why this is happening requires a look at what Snap does under the hood and why Steam is a particularly bad fit for that model.

Two Sandboxes Fighting Each Other

Snap packages run inside a confined environment enforced by snapd, AppArmor, and seccomp filters. This confinement is the point: it restricts what an application can access on the host system. For a text editor or a media player, that is generally fine. For Steam, it creates a fundamental architectural conflict.

Steam on Linux does not behave like a single monolithic application. It is closer to a framework: it manages its own internal runtime called the Steam Linux Runtime (SLR), which in turn uses a container system called Pressure Vessel to isolate games. Pressure Vessel is built on top of Bubblewrap, the same low-level sandboxing tool that Flatpak also relies on. When Steam runs a game via Proton, the game runs inside a container that Steam itself creates and manages.

A tracking issue opened by a Canonical gaming team member on the steam-snap GitHub repository in early 2024 acknowledged this directly, noting that "Steam sandboxing breaks almost every time a change is made to Snap" and that diagnosing errors required determining whether a problem originated from the AppArmor profile, a deeper snapd quirk, a Steam issue, or some interaction between all three. The issue described the maintenance burden as unsustainable given the team's size and the rate of change in both codebases. (steam-snap issue #363, GitHub)

Concrete symptoms of this conflict appear throughout the steam-snap issue tracker. A report from January 2024 documented Proton games crashing with the error bwrap: Can't mount tmpfs on /newroot/var/pressure-vessel/ldso: Permission denied -- a Bubblewrap mount failure caused directly by the AppArmor profile refusing the operation. (steam-snap issue #356) Another long-standing issue reported that none of the affected user's Proton games would launch at all under snap. (steam-snap issue #372)

How to read AppArmor denials yourself

If you are still running the Steam Snap and want to confirm whether AppArmor is blocking operations, the denials appear in the kernel audit log. On Ubuntu, the most direct way to read them is:

# Requires auditd or journald with kernel audit events enabled
$ sudo journalctl -k | grep -i "apparmor.*DENIED.*snap.steam"

# Alternatively, check the kernel ring buffer directly:
$ sudo dmesg | grep -i "apparmor.*DENIED"

A denial entry looks like: apparmor="DENIED" operation="mount" profile="snap.steam.steam" name="/newroot/var/pressure-vessel/ldso" pid=XXXX comm="bwrap" requested_mask="mount" denied_mask="mount" fsuid=1000 ouid=0. The profile="snap.steam.steam" field confirms the block is being applied by snapd's AppArmor profile, not by the kernel or Valve's code. If you see entries like this while trying to launch Proton games, the root cause is the packaging layer -- not the game, not Proton, and not your GPU drivers.

The Steam Snap's AppArmor profile is stored at /var/lib/snapd/apparmor/profiles/snap.steam.steam on systems where it is installed. It is a generated file managed entirely by snapd -- you should not edit it manually, as snapd will overwrite changes on the next update. This is part of why Canonical's only practical fix for the Pressure Vessel conflicts in snapd 2.65 was to remove the restrictions wholesale rather than write a profile precise enough to allow them selectively.

The user namespace error you will see everywhere

The single most commonly reported error from this conflict is bwrap: setting up uid map: Permission denied or bwrap: No permissions to creating new namespace. This occurs because Pressure Vessel needs unprivileged user namespaces to set up its container, and the AppArmor profile (or, on hardened kernels, the kernel.unprivileged_userns_clone sysctl) blocks the call. Ubuntu 24.04 tightened AppArmor restrictions around user namespaces specifically to reduce attack surface, which had the side effect of making this failure more frequent for the Steam Snap. (steam-runtime issue #640)

You will find forum posts suggesting sudo chmod u+s /usr/bin/bwrap as a workaround. This sets the SUID bit on Bubblewrap, allowing it to create namespaces regardless of the kernel's unprivileged restriction. It does resolve the immediate error, but it also means every application on your system that uses Bubblewrap now runs its sandbox initialization with root privileges -- a broader security trade-off than simply switching to the native .deb install, which avoids the conflict entirely.

The Other Issues: Paths, Permissions, and Opacity

The sandbox conflict is the biggest problem, but it is not the only one. Snap's confinement model also creates a range of secondary issues that degrade the gaming experience in ways that are harder to diagnose.

Library locations are wrong

Snap packages isolate their data under ~/snap/steam/common/ rather than the standard ~/.local/share/Steam/ path. This causes steam-snap to report the wrong default installation directory for games in some configurations. A reported issue from March 2024 documented the Snap version of Steam suggesting /boot as the default game installation location -- not because Steam intended that, but because the Snap's view of the filesystem was distorted. (steam-snap issue #373)

External drives require manual intervention

Access to drives and partitions outside the Snap sandbox is blocked by default. Users who store their game libraries on a secondary drive or NFS share must manually connect the removable-media interface using sudo snap connect steam:removable-media. Even then, behavior can be inconsistent, particularly when mount points live under non-standard paths. A Valve developer (smcv, a Steam Runtime maintainer) filed steam-snap issue #289 documenting that Pressure Vessel's bind-mount of its container runtime from /media/ or /mnt/ paths failed with Permission denied even after the removable-media interface was connected, because the AppArmor profile only allowed bind-mounts from paths under /home/. (steam-snap issue #289)

Users often do not know they have the Snap version

Canonical's App Center (and the older Ubuntu Software Center) presents Snap packages alongside other software without prominent labeling. On Ubuntu 22.04 and later, installing Steam via the graphical store often defaults silently to the Snap version. A user experiencing crashes has no obvious reason to connect their symptoms to a packaging format they may never have knowingly chosen.

The steam-snap issue tracker itself acknowledged this problem, noting that reports of Snap-specific bugs frequently end up on Valve's own issue tracker because users and even developers cannot reliably tell at a glance which installation type they are dealing with. Valve's team then has to triage issues that are not their responsibility. (steam-snap issue #363)

SteamVR is explicitly broken

Valve's SteamVR is a recurring point of failure under the Snap packaging. Community reports from the Steam for Linux forums indicate that both the Snap and Flatpak versions of Steam have been associated with SteamVR errors, with multiple users recommending the native .deb as the only reliable path for VR gaming on Ubuntu. (Steam Community Forums)

Canonical is actively pushing the Snap version harder

In February 2025, a thread on the Ubuntu Community Discourse titled "Time to sunset the steam-installer deb?" proposed removing the traditional .deb Steam package from Ubuntu's own repositories entirely, arguing that the Snap version is now the preferred path. Participants discussed hiding the .deb option behind the Snap in the App Center. For users who depend on Valve's official .deb via repo.steampowered.com, this means the Snap could become even more aggressively defaulted in future Ubuntu releases -- making it more important to have Valve's repository configured directly rather than relying on whatever Ubuntu's package store surfaces. (Ubuntu Discourse, February 2025)

Step 0: Detect Whether You Have the Snap Version

Before removing anything, confirm which version of Steam is installed. Run the following in a terminal:

$ snap list | grep steam

If you see output like steam 1.0.0.x xxx latest/stable canonical -, you are running the Snap version. If the command returns nothing, you are not. You can also check:

$ which steam
# If the path starts with /snap/bin/, it is the Snap version
# If it is /usr/bin/steam or /usr/games/steam, it is a native install

Step 1: Remove the Snap Version of Steam

Close Steam completely before proceeding. Then run:

$ sudo snap remove steam

# Skip the data snapshot -- faster if you already backed up steamapps/
$ sudo snap remove steam --purge

If even --purge fails with an error like unlinkat ... directory not empty, manually clear the residual data first, then retry:

$ sudo rm -rf ~/snap/steam
$ sudo rm -rf /var/snap/steam
$ sudo snap remove steam --purge

This removes the Snap package and its associated data directories under ~/snap/steam/. Note that if you have game data stored there and did not back it up beforehand, it will be gone. The Snap removal process on Ubuntu has also been reported to hang indefinitely in some cases when attempted through the GUI App Center. (ubuntu/app-center issue #1898) The terminal command above is the more reliable path.

After removal, verify it is gone:

$ snap list | grep steam
# Should return nothing

Step 2: Install Steam via Valve's Official Repository

Valve maintains its own APT repository at repo.steampowered.com. This is the installation method Valve's engineer directly recommended. It delivers the same client as the downloadable .deb from the Steam website, updated through standard apt tooling, with no Snap involvement.

The following steps work on Ubuntu 22.04, 24.04, and 24.10, as well as Debian-based derivatives like Linux Mint and Pop!_OS. The GPG key URL and repository location below come directly from Valve's official repository landing page at repo.steampowered.com/steam/.

1. Enable 32-bit architecture support

Steam and Proton require 32-bit libraries for compatibility with many Windows games. This is a one-time system-level change:

$ sudo dpkg --add-architecture i386
$ sudo apt update

2. Download and install Valve's GPG signing key

$ curl -fsSL https://repo.steampowered.com/steam/archive/stable/steam.gpg \
  | sudo gpg --dearmor -o /usr/share/keyrings/steam.gpg

3. Add the Steam APT repository

$ sudo tee /etc/apt/sources.list.d/steam-stable.list <<'EOF'
deb [arch=amd64,i386 signed-by=/usr/share/keyrings/steam.gpg] \
    https://repo.steampowered.com/steam/ stable steam
deb-src [arch=amd64,i386 signed-by=/usr/share/keyrings/steam.gpg] \
    https://repo.steampowered.com/steam/ stable steam
EOF

$ sudo tee /etc/apt/sources.list.d/steam.sources <<'EOF'
Types: deb
URIs: https://repo.steampowered.com/steam/
Suites: stable
Components: steam
Architectures: amd64 i386
Signed-By: /usr/share/keyrings/steam.gpg
EOF

4. Install Steam and its required OpenGL libraries

$ sudo apt update
$ sudo apt install \
    libgl1-mesa-dri:amd64 \
    libgl1-mesa-dri:i386 \
    libgl1-mesa-glx:amd64 \
    libgl1-mesa-glx:i386 \
    steam-launcher

The steam-launcher package is the bootstrapper. On first launch it will download the full Steam client. Accept the Steam subscriber agreement when prompted.

Verify the installation source

After installation, confirm that APT is resolving steam-launcher from Valve's repository and not from any other source:

$ apt policy steam-launcher
# The "Candidate" line should show repo.steampowered.com

$ which steam
# Should return /usr/bin/steam or /usr/games/steam -- NOT /snap/bin/steam

$ snap list | grep steam
# Should return nothing if the Snap is fully removed

If apt policy shows a different source, or which steam returns a snap path, your system may still have a residual snap installation or an apt alias redirecting to snapd. See the Prevent Reinstall section below.

Alternative: The Flatpak Route

Valve's engineer mentioned Flatpak as a secondary option. It is worth being precise about what this means: the Flatpak version of Steam, available at Flathub, is also not officially maintained by Valve. It is a community-maintained package, like the Snap. However, it has generally been more stable for Proton games because Flatpak's sandboxing model (also built on Bubblewrap) is architecturally closer to how the Steam Runtime already operates.

As EagleDelta, a frequent contributor to the GamingOnLinux community, noted in June 2024: the consistent underlying problem with Snap is that it handles sandboxing in a way that conflicts with Pressure Vessel, while Flatpak has fewer of these collisions because both share the same foundational technology. (GamingOnLinux, June 2024)

That said, for Debian and Ubuntu users, the Valve APT repository is the cleaner choice. Flatpak adds another sandboxing layer on top of the runtime, which can complicate access to external game library locations. If you want to install Steam via Flatpak anyway:

$ sudo apt install flatpak
$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak install flathub com.valvesoftware.Steam
$ flatpak run com.valvesoftware.Steam

Step 3: Restore Your Game Library

If you moved your steamapps/ folder before the removal, you can point the native Steam install at it without re-downloading anything. After Steam has launched for the first time via the new install:

Go to Steam > Settings > Storage, then click Add Drive and point it to the folder containing your steamapps/ directory. Steam will scan for and recognize all installed games automatically.

If your games were stored in the default Snap path at ~/snap/steam/common/.local/share/Steam/steamapps/ and you did not move them before removal, they were deleted when you ran snap remove steam. In that case, you will need to reinstall them. Your save data for games using Steam Cloud will sync back automatically on launch.

Optional: Install Proton GE for Better Compatibility

Proton GE (GloriousEggroll's community build) is a fork of Valve's Proton that includes additional patches, staging updates, and codec support not yet merged into the official build. It often resolves compatibility issues with specific games before those fixes reach the official Proton release.

With the native .deb install, Proton GE installs to the standard location:

# Create the compatibility tools directory if it does not exist
$ mkdir -p ~/.steam/steam/compatibilitytools.d/

# Download a release from https://github.com/GloriousEggroll/proton-ge-custom/releases
# Then extract it to the directory (replace VERSION with the actual release)
$ tar -xf GE-ProtonVERSION.tar.gz -C ~/.steam/steam/compatibilitytools.d/

# Restart Steam, then select it via:
# Right-click game > Properties > Compatibility > Force the use of...

Under the Snap version, this same process required extracting to ~/snap/steam/common/.steam/steam/compatibilitytools.d/, an awkward path that changes with Snap revisions. GloriousEggroll's own documentation explicitly notes that the Snap installation path is unsupported and behaves differently from upstream builds. (proton-ge-custom, GitHub)

Verifying which Proton version actually ran your game

One thing the Steam UI does not expose clearly is which Proton build was actually invoked for a given game launch. With the native .deb install, you can check this from the Steam log files. After launching a game, look at the most recent Proton log:

# Find the Steam log for your game (replace APP_ID with the game's Steam App ID)
$ cat ~/.steam/steam/logs/steam_log.txt | grep -i "proton" | tail -20

# Or check the Proton log file directly (lives under the game's compatdata path)
$ ls ~/.steam/steam/steamapps/compatdata/APP_ID/
$ cat ~/.steam/steam/steamapps/compatdata/APP_ID/config_info

The config_info file records the Proton version string that was active when the prefix was last initialized. Under the Snap packaging, the compatdata path lives at ~/snap/steam/common/.local/share/Steam/steamapps/compatdata/ -- a different location that third-party tools like ProtonUp-Qt and protontricks must be told about explicitly, and frequently are not.

Has Snap Steam Actually Gotten Better?

In fairness, Canonical has been working on the problem. With snapd 2.65, released in late 2024, Canonical removed all AppArmor and seccomp restrictions from the Steam Snap, giving Steam's own runtime more direct control over its containers. An October 2024 report from OMG! Ubuntu noted that anecdotally, launch times had improved and were reportedly on par with the .deb version for some users. (OMG! Ubuntu, October 2024)

The removal of those restrictions does help. But it also illustrates the fundamental problem: to make Snap work adequately with Steam, Canonical had to largely abandon the confinement that is Snap's primary value proposition. The Steam Snap is now effectively a Snap in name, running with substantially relaxed sandboxing. Whether you consider that an acceptable tradeoff depends on why you were using Snap in the first place.

AppArmor denial errors have continued to appear in practice even after snapd 2.65. A report from November 2024 on Ubuntu 24.10 documented apparmor="DENIED" audit log entries blocking snap-confine from reading /proc/ maps, causing the Steam icon launch to silently fail while terminal launch succeeded. (steam-snap issue #420, GitHub) The Snap package itself remains actively maintained -- the latest/candidate channel was updated on April 9, 2026 (snapcraft.io/steam) -- but Valve's official position has not changed: they do not maintain or support the Snap package, and the official .deb is what they stand behind.

The broader security picture: snap-confine's track record

CVE-2026-3888 is not the first time snap-confine has been the point of failure. The Qualys Threat Research Unit has found privilege escalation vulnerabilities in this same component three separate times in five years:

• CVE-2021-44731 (CVSS 7.8) -- A race condition in snap-confine's setup_private_mount() that allowed any unprivileged user to gain root on default Ubuntu Desktop installs. Qualys demonstrated full exploitation. (Qualys TRU, February 2022)
• CVE-2022-3328 (CVSS 7.8) -- A race condition in snap-confine's must_mkdir_and_open_with_perms() that Qualys chained with two multipathd vulnerabilities to achieve full root. (Qualys TRU, November 2022)
• CVE-2026-3888 (CVSS 7.8) -- The current timing-based privilege chain between snap-confine and systemd-tmpfiles.

All three target the same structural weakness: snap-confine is a SUID-root binary that initializes mount namespaces, AppArmor profiles, and seccomp filters for every Snap launch. It sits at a critical privilege boundary, and any flaw in how it handles mount operations, file permissions, or race conditions translates directly to root. Each Snap package installed on your system increases the frequency at which snap-confine executes with elevated privileges, which is why reducing your Snap footprint -- not just patching -- is a meaningful defense.

What Proton exposes and why the packaging layer matters

There is a related security consideration that applies regardless of packaging format, but is worth understanding in the context of what Snap's confinement was supposed to provide. Every Proton game prefix contains a dosdevices/Z: symlink that maps to / -- the entire root filesystem. A Windows game running under Proton can read (and in some cases write to) any file that the user's Unix permissions allow. This is a documented design choice in Wine, and Proton inherits it. (Proton issue #3979, GitHub)

Under the Snap model, AppArmor confinement was supposed to limit this exposure. But as of snapd 2.65, Canonical removed all AppArmor and seccomp restrictions from the Steam Snap. The Snap now runs with effectively the same filesystem access as the native .deb -- but it still invokes snap-confine with root privileges on every launch, adding an attack surface that the native install does not carry. You get the security costs of the Snap infrastructure without the confinement benefits that were supposed to justify them.

A new security risk: CVE-2026-3888

In March 2026, Qualys disclosed CVE-2026-3888, a high-severity local privilege escalation vulnerability affecting default installations of Ubuntu Desktop 24.04 and later. Rated CVSS 7.8 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) and classified under CWE-268 (privilege chaining) by the National Vulnerability Database, the flaw arises from an interaction between two system components: snap-confine (the set-user-ID-root utility that initializes Snap sandboxes) and systemd-tmpfiles (which periodically cleans stale entries under /tmp). An unprivileged local attacker exploits a specific timing window: they wait for systemd-tmpfiles to delete the /tmp/.snap directory during its cleanup cycle -- which happens after 30 days on Ubuntu 24.04 and after 10 days on later releases -- then recreate it with attacker-controlled content. When snap-confine next initializes a Snap sandbox, it bind-mounts those files with root privileges, enabling arbitrary code execution at root level. (Qualys TRU, March 17, 2026 / Ubuntu Security / NVD)

Canonical's own security notice describes the flaw as arising because snapd "incorrectly handled certain operations in the snap's private /tmp directory," with systemd-tmpfiles cleanup enabling an attacker to recreate the deleted path and escalate privileges.

-- Canonical, CVE-2026-3888 Ubuntu Security Notice (ubuntu.com/security/CVE-2026-3888)

Canonical has issued patched snapd packages: 2.73+ubuntu24.04.2 for Ubuntu 24.04 LTS, 2.73+ubuntu25.10.1 for Ubuntu 25.10, and 2.74.1+ubuntu26.04.1 for Ubuntu 26.04 (dev). The vulnerability is resolved on systems that have applied updates. You can verify your snapd version with:

$ snap version
# Check the 'snapd' line -- compare against the patched versions above

# Or check via dpkg for the exact installed build:
$ dpkg -l snapd | grep snapd

But CVE-2026-3888 is a meaningful data point beyond the immediate patch: it demonstrates that the attack surface introduced by snapd and snap-confine is not purely a gaming compatibility concern. The NVD's CWE-268 classification -- privilege chaining -- reflects that this is not a single broken permission check but a path that chains scheduled cleanup, writable temporary state, namespace setup, bind mounts, and privileged execution into a coherent attack. Every Snap package on your system, including the Steam Snap, requires snap-confine to be running with elevated privileges. Removing Snap packages you do not need -- starting with Steam, which has a fully functional native alternative -- directly reduces the exposure of that attack surface on your machine.

Preventing Ubuntu from Silently Reinstalling the Snap

On Ubuntu, certain APT package names are aliased to Snap packages. If you later run sudo apt install steam without the Valve repository configured, Ubuntu may silently route that to the Snap store instead. To prevent this after setting up the Valve repository, the steam-launcher package name from Valve's repo takes priority, but it is worth verifying your APT policy is pointing to the right place:

$ apt policy steam-launcher
# Should show repo.steampowered.com as the candidate source

$ snap list | grep steam
# Should return nothing if the Snap is gone

If you want to go further and prevent snapd from being used for Steam at the apt level, you can pin it. Create a preference file:

# Prevent apt from routing steam requests to snapd
Package: steam
Pin: release o=Ubuntu
Pin-Priority: -1

On Ubuntu 24.04 and later you can also use apt-mark hold on the Valve package to prevent it from being accidentally replaced:

# Optional: hold the Valve package at its current version
$ sudo apt-mark hold steam-launcher

# To undo when you want to update Steam normally:
$ sudo apt-mark unhold steam-launcher

Post-Migration Health Check

After completing the migration, run through this quick diagnostic to confirm everything is clean. This is a single block you can paste into a terminal:

# 1. Confirm no Steam Snap remains
$ snap list 2>/dev/null | grep -q steam && echo "FAIL: Steam Snap still installed" || echo "OK: No Steam Snap"

# 2. Confirm steam-launcher is from Valve's repo
$ apt-cache policy steam-launcher 2>/dev/null | grep -q "repo.steampowered.com" && echo "OK: Valve repo active" || echo "WARN: Valve repo not found in policy"

# 3. Confirm steam binary is native (not snap)
$ which steam | grep -q "/snap/" && echo "FAIL: steam resolves to snap path" || echo "OK: steam path is native"

# 4. Confirm 32-bit architecture is enabled
$ dpkg --print-foreign-architectures | grep -q i386 && echo "OK: i386 architecture enabled" || echo "FAIL: i386 not enabled"

# 5. Confirm snapd is patched for CVE-2026-3888
$ snap version 2>/dev/null | grep snapd || echo "snapd not installed (not a concern)"

# 6. Check for residual AppArmor denials from old snap profile
$ sudo journalctl -k --since "1 hour ago" 2>/dev/null | grep -c "apparmor.*DENIED.*snap.steam" | xargs -I{} echo "AppArmor snap.steam denials in last hour: {}"

If all lines return OK, your migration is complete and clean. A "FAIL" on any check means the corresponding step above was either skipped or did not complete successfully. The snapd version check at step 5 is relevant even after removing the Steam Snap, because snapd itself remains installed on Ubuntu for core system packages -- and CVE-2026-3888 affects that daemon regardless of which individual Snap packages are installed.

The Practical Summary

The Steam Snap package on Ubuntu is not a neutral alternative to the native install. It is a third-party repackaging that Valve does not endorse, does not test against, and does not want bug reports from. The structural conflict between Snap's sandboxing and Steam's own runtime containerization is real, documented in Canonical's own issue tracker, and has been causing silent failures for users who had no idea they were running a non-standard configuration.

In March 2026, a high-severity privilege escalation vulnerability (CVE-2026-3888, CVSS 7.8, CWE-268) disclosed by Qualys added a new dimension to the picture: snap-confine, the elevated-privilege component that manages Snap sandboxes, carries its own security attack surface. Keeping Snap packages you do not need -- including Steam, which has a fully supported native alternative -- is a direct way to reduce exposure to that class of vulnerability on your machine.

The corrective steps are straightforward: detect the Snap with snap list, remove it with sudo snap remove steam, and install from Valve's APT repository at repo.steampowered.com using the steps above. That gives you a Steam install that Valve actually tests, ships, and supports -- where game library access is unrestricted, Proton runs as designed, and debugging an issue means looking at Valve's code rather than trying to untangle three layers of packaging from two different organizations.

If you have been chasing mysterious game crashes, Proton launch failures, or SteamVR errors on Ubuntu, there is a reasonable probability you just found the root cause. The fix takes about five minutes.