Installing Soldier after setting up an NTFS library cause Proton to stop working.

[MatteAce]

Proton 6.3.5 and previous versions, on KDE-Arch

• Install Steam
• Go to Settings/Download
• Add an existing NTFS library (with the NTFS drive mounted correctly as for the Proton FAQ)
• Turn on Steamplay/Proton
• Launch a game preinstalled on the NTFS drive.

Soldier will be downloaded, but it will break Proton, which will stop working for the majority of the cases (it still worked for Tekken 7 though).

To make Proton work again:

• Uninstall Soldier
• Remove the NTFS library from Steam
• Install any small non-native game on the ext4 partition (I used Rogue)
• Launch the game: Soldier will be installed again.
• The game should be working now
• Go back to Settings/Download and add the NTFS partition again
• Now all the non-native games should work with Proton correctly.

[smcv]

with the NTFS drive mounted correctly as for the Proton FAQ

Please specify exactly which filesystem type and mount options you are using, so that if the recommendation in the Proton FAQ changes, we can still try to reproduce the issue from what you wrote here?

Soldier will be downloaded, but it will break Proton

What exactly does "break Proton" mean here? (Symptoms, error messages, etc.)

In the non-working situation, is steamapps/common/Proton 6.3 in the Steam Library directory on your NTFS mount point, or in the Steam Library directory on an ext4 mount point?

In the non-working situation, is steamapps/common/SteamLinuxRuntime_soldier in the Steam Library directory on your NTFS mount point, or in the Steam Library directory on an ext4 mount point?

In the non-working situation, is the game (steamapps/common/Rogue or similar) in the Steam Library directory on your NTFS mount point, or in the Steam Library directory on an ext4 mount point?

In the working situation, same three questions?

Please can you gather a log in the non-working situation? If this is a bug in soldier, then the information we need is here: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information. If it's a bug in Proton, then the Proton developers will need the Proton log generated by running Steam with PROTON_LOG=1 (the default location is ~/steam-<gameID>.log). It's best if you run Steam with STEAM_LINUX_RUNTIME_LOG=1 PROTON_LOG=1 steam so that you get both logs from the same run.

[smcv]

In general, a Steam library on ntfs-3g is meant to work (I used this on my own gaming PC until recently), although it's less robust than a typical Linux filesystem like ext4, btrfs or xfs. Other NTFS implementations like the ntfs kernel module are unlikely to work.

There are up to three Steam Library directories that matter for a Proton game, although all three will often be the same:

• the Steam library that contains Proton (steamapps/common/Proton 6.3 or similar)
• the Steam library that contains steamapps/common/SteamLinuxRuntime_soldier
• the Steam library that contains the actual game, for example steamapps/common/Floating Point, and its compatdata directory, for example steamapps/compatdata/302380

If you are using ntfs-3g, there are three [edit: four] main things that could potentially be breaking this:

1. NTFS is case-insensitive but case-preserving, which sometimes confuses the bwrap tool that we use.

2. We need support for some Unix filesystem features: SteamLinuxRuntime_soldier must be on a filesystem that supports symbolic links (ln -s) and hard links (ln), the actual game must be on a filesystem that supports at least symbolic links (ln -s), and Proton might have similar requirements. ntfs-3g provides these features, so this is hopefully not the problem.

3. Proton has some filenames that Windows would not allow, notably dosdevices/c:. These appear in the compatdata directory, which is in the same Steam library as the actual game, so that directory must not be on a filesystem that is mounted with the windows_names option. The Proton 6.3 directory might have similar requirements.

4. Proton and SteamLinuxRuntime_soldier both want to set the permissions on files, which means the files must be owned by the same user who is running Steam. For example, if Steam is running as user ID 1000, then the NTFS partition will usually need to be mounted with uid=1000 in the mount options.

[PhilArmstrong]

There‘s a bug I‘m in the process of narrowing down before reporting it with the current steam linux runtime where if you have files owned by a different user to you in the runtime install (in my case this was due to a steam library folder that was shared between multiple linux users & a different user had installed the soldier & scout runtimes) the construction of the runtime namespace container for running the game fails with a “fchmod() unable to set permissions on /bin/[' error. The file has been hardlinked into the container & then the chmod call fails, as the file is not owned by the caller I think, even though the caller has write permissions.
Could this be the same thing? The ntfs-3f mount may well have the files owned by a different user to the steam user & so the same permissions error would then presumably occur?

[PhilArmstrong]

Ah, see point 4 you‘ve made above. NB, this makes sharing a steam library problematic with current Proton releases. I think the only way to make it work is to install games into the shared library, but install the runtimes into each users‘ /home directory, so they have the appropriate ownership.
Is a shared steam library meant to be a supported setup under Linux?

[smcv]

this makes sharing a steam library problematic with current Proton releases

Sorry, I don't think that's intended to be a supported use-case.

Sharing like this will definitely defeat any security boundary that you had intended to have between the users, because each user will run arbitrary executables from the Steam library, so a user who wants to get another user's privileges can just overwrite a frequently-run executable or script (like part of SLR or Proton) with their own crafted version, and wait for the victim to run it.

[smcv]

the construction of the runtime namespace container for running the game fails with a “fchmod() unable to set permissions on /bin/[' error

The problem here is that, as you've said, we can't chmod() another user's files. It's also non-trivial to tell whether the permissions that the file already had are "good enough" or not. We canonicalize files' permissions to 0755 or 0644, but on a shared NTFS or FAT filesystem, they'll often be 0775 or even 0777. If we ask to chmod() our own files to an unsupported value, the NTFS driver will silently ignore that; but if we ask to chmod() a file and it fails, we can't tell the difference between 0775 or 0777 in an intentionally shared directory between mutually trusting users (intentional), and 0775 or 0777 on a system with mutually distrusting users (a security vulnerability).

[PhilArmstrong]

Given that this use case works fine under Windows, why can‘t it be a goal to have it work under Linux too? It seems like a thing that ought to be possible, at least to the same level of security that you get under Windows, such as it is...

Anyway, will leave this here - if it‘s not going to be a design goal to permit this, then that‘s the way things are.

[smcv]

The problem here is that, as you've said, we can't chmod() another user's files. It's also non-trivial to tell whether the permissions that the file already had are "good enough" or not.

In this situation, today's Steam Linux Runtime 2.0 (soldier) and Steam Linux Runtime 3.0 (sniper) betas (versioned 0.20230905.x) will make an attempt to run anyway. It might work, or it might not, depending how your filesystem is configured and how good your luck is.

[edited to add] This applies equally to both the original report here (Steam Linux Runtime tools on a NTFS filesystem), and the slightly different scenario in #434 (comment) (Steam Linux Runtime tools on a native Linux filesystem, but owned by a different Unix user ID).

The affected configurations are still not recommended - the recommended layout is to have all Steam libraries on native, local Linux filesystems (ext4, btrfs, xfs or similar), owned by the same user ID that runs Steam - but the container runtime tool will now try its best. The container runtime tool will log warnings on stderr in this situation, and if the filesystem is not identifiable as a native, local Linux filesystem, Help -> System Information will flag it as a (potential) issue. That's as much as anyone can do here, so I think this issue can be closed when those changes get into a stable release.

Please note that Proton is outside the scope of the steam-runtime project and this issue, and it intentionally does not allow being shared between different Unix user IDs (that's ValveSoftware/Proton#4820 and will not be addressed here). You'll still need to install Proton on a per-user basis.

Sharing like this will definitely defeat any security boundary that you had intended to have between the users, because each user will run arbitrary executables from the Steam library, so a user who wants to get another user's privileges can just overwrite a frequently-run executable or script (like part of SLR or Proton) with their own crafted version, and wait for the victim to run it.

This is still true. It'll be true in the equivalent scenario on Windows, too.

[benny-dreamly]

I'm having the same issue, but proton litterally just won't load from games installed on an ntfs disk