Mapped drives not usable with steam and non-steam apps.

[jarrard]

After setting D: and E: drives via winecfg using protontricks (I know its not officially supported), and verifying they exist in the registry, the applications I launch via proton can't access those drives citing either permission issues or similar.

I have tested this under Lutris without any issues, I do not know why steam is doing this.

Anyone have input? I do not wish to link everything via z:/mnt/xxxx as it messes up my configuration files. This kind of issue never use to be a problem, but now it is!

[kisak-valve]

Hello @jarrard, starting with Proton 5.13, Proton is run inside of the Steam Linux Runtime - Soldier container environment, and this container environment does not have unlimited access to the host system. Let's treat this as a Steam Linux Runtime - Soldier issue until there's a stronger indication the issue is elsewhere.

You're most likely seeing a mix of https://github.com/ValveSoftware/steam-runtime/issues/393 and https://github.com/ValveSoftware/steam-for-linux/issues/6046 that you may be able to work around by starting Steam with STEAM_COMPAT_MOUNTS=/path/to/unexpected/folder steam

[jarrard]

hmm, ok I will check this out and see if it resolves the issue.

[smcv]

I do not wish to link everything via z:/mnt/xxxx

This wouldn't help: the problem is that the container used to run Proton didn't have access to your /mnt, so /mnt/xxxx wouldn't be visible either as D:\ or as Z:\mnt\xxxx in the Wine environment.

[smcv]

Starting from pressure-vessel version 0.20220803.0 in today's "Steam Linux Runtime - soldier" and "Steam Linux Runtime - sniper" betas, more top-level directories are available to games by default, reducing the need to use STEAM_COMPAT_MOUNTS.

If you want to try using a beta version, the procedure to opt-in to a beta is the same as for any Steam game, except instead of looking for a game in your Steam library, you'd look for "Steam Linux Runtime - soldier" and choose the client_beta branch. If this version works well, the change will be copied into the default branch at some point in the future (I can't make any promises about timing, but it's usually 1 or 2 months between updates). Please report any regressions to the Steam Runtime issue tracker.

The affected paths are the typical paths for removable media:

• /media: FHS parent directory for removable media mount points
• /mnt: FHS traditional/legacy temporary mount point
• /run/media: widely-used alternative to /media

and some FHS locations where people often put the mount points for non-removable but non-OS drives and partitions, such as a secondary SSD or HDD:

• /home: FHS parent directory for home directories
• /opt: FHS directory for self-contained third-party software
• /srv: FHS directory for site-specific services' data

Custom top-level directories like /stuff are not shared by default, and still require use of STEAM_COMPAT_MOUNTS, because we can't automatically classify unknown top-level directories into things you would expect to be shared (/storage, /games, /large-disk-drive) and things you would not expect to be shared (future OS components, /lost+found, /corporate-secrets).

However, the paths you're talking about in this issue are covered by this change, so with this change you shouldn't need STEAM_COMPAT_MOUNTS any more.

Technical details

[smcv]

Starting from pressure-vessel version 0.20220803.0 in today's "Steam Linux Runtime - soldier" and "Steam Linux Runtime - sniper" betas, more top-level directories are available to games by default, reducing the need to use STEAM_COMPAT_MOUNTS.

This change was promoted from beta to the default branch today.

[jarrard]

Wonder what TOP LEVEL means. I'd be happy if everything in /mnt/ folder is made available.

[kisak-valve]

Any folder that can be found in /, the top level of the folder tree.

[jarrard]

Ok well lets just close this for now until someone comes up with a problem. :)

Cheers

[smcv]

I'd be happy if everything in /mnt/ folder is made available.

Be happy, then, because that's part of the change I described.

(In general, whenever the container runtime shares a path with the container, it shares it recursively, so everything "below" that path is included; for instance access to /mnt implies access to /mnt/windows/c/Program Files/Whatever.)