Proton not working when multiple Linux users share a single installation path

[Maykin-99]

I've followed these instructions on Reddit to allow multiple Linux users to share the same installation folder without dealing with permission issues. That seems to work so far for Linux-native games.

The issue with Proton games is that Wine does not allow using a Wine-Prefix that doesn't belong to the current user.

Example:

Both Steam clients on both Linux accounts are configured to download the games in /opt/games/Steam.

User maykin installs a Windows game and a Wineprefix in /opt/games/Steam/steamapps/compatdata/430190/pfx is created.

User steamuser wants to play the same game.
It does not need to install the game again, since maykin already installed it.
When attempting to start the game nothing happens (no game & no error message).
When inspecting the logs the following error occur:

Installing breakpad exception handler for appid(steam)/version(1618256785)
Proton: Upgrading prefix from 5.13-1 to 6.3-2 (/opt/games/Steam/steamapps/compatdata/430190/)
Proton: Removing stale builtin /opt/games/Steam/steamapps/compatdata/430190/pfx//drive_c/windows/system32/amd_ags_x64.dll
Proton: Removing stale builtin /opt/games/Steam/steamapps/compatdata/430190/pfx//drive_c/windows/syswow64/amd_ags_x64.dll
wine: '/opt/games/Steam/steamapps/compatdata/430190/pfx' is not owned by you
wine: '/opt/games/Steam/steamapps/compatdata/430190/pfx' is not owned by you
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wineserver: /opt/games/Steam/steamapps/compatdata/430190/pfx is not owned by you
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/steamuser/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
wine: '/opt/games/Steam/steamapps/compatdata/430190/pfx' is not owned by you

The relevant part is (so I assume) wine(server): /opt/games/Steam/steamapps/compatdata/430190/pfx is not owned by you.

The directory is owned by maykin but steamuser has read and write access to it but Wine - for security reasons apparently - doesn't care and demands that the prefix is owned by the current user, i.e. steamuser.

My suggestion:

1. Create a new prefix per user:
   Instead of creating the prefix here: /opt/games/Steam/steamapps/compatdata/<gameid>/pfx we could place it there: /opt/games/Steam/steamapps/compatdata/<gameid>/pfx/<userid>
2. Use symbolic links so that all prefixes share the same data:
   Put the device_c in a separate directory outside the prefix, e.g. in /opt/games/Steam/steamapps/compatdata/<gameid>/data, and place a symbolic link in /opt/games/Steam/steamapps/compatdata/<gameid>/pfx/<userid/device_c that points to the data directory

[kisak-valve]

Hello @Maykin-99, upstream wine does not allow the wine prefix to be being owned by another user to prevent an entire category of problems. Proton inherits this behavior and ideally, your issue would need to be evaluated and resolved upstream with vanilla wine before looking at it here.

[aeikum]

I'm pretty sure this is a Steam client limitation more than anything else. You're not intended to share Steam Library folders between users. Some applications do stupid things like write files directly into the Library folders, which can fail with multiple users.

[Maykin-99]

@kisak-valve: I'm sure Wine does what it does for a good reason. In fact, if we look into their forum it states "Risk of of registry corruption" as the reason: Link

In the same post it also suggests creating a wine prefix for each user and store the data outside of it:

If you just want to save space, you can install apps to a single directory shared by multiple users outside their wineprefixes. You will have to run the installer for each user to create the needed registry entries for each, but just point the installer to the shared directory instead of accepting the default in Program Files when it asks where you want to install the app to. Make sure all users have read/write permissions for that directory.

So I simply ask Valve to follow their advice.

@aeikum

I'm pretty sure this is a Steam client limitation more than anything else.

I'm honestly not sure which piece of software (Steam Client vs. Proton) is configuring wineprefix. I'll reference this issue in the steam-for-linux repository.

You're not intended to share Steam Library folders between users.

I disagree. It works in Windows and I expect it to work in Linux as well.

Some applications do stupid things like write files directly into the Library folders, which can fail with multiple users.

Though in my experience this only causes that save games & configurations are shared unintendedly. And I don't expect Valve to fix game developer's "stupid things".

[EgorIII]

i've spend evening trying to launch game on my notebook for my friend to get to this issue.

Can we at least for now have some proper error pop up?

Cause right now if you try to do that steam will do funny: button is blue cause game is running, oh and now button is green to launch it again like nothing happened whatsoever, and even error text in console does not provide that much information, cause i was setting that share library permission to all kinds of stuff.

[geoffryan]

Just adding a voice to the chorus, it would be lovely if this could be fixed. We have a single Linux computer shared by the household. Games are massive, so we install them to a shared directory and use Family Sharing to share the games, but of course run into this proton permissions issue. I don't see the point of local family sharing if you still have to install games per-user.

[jessecambon]

Also wanted to add that this would be a really useful addition. I am trying to share a game library between an admin account that is meant for regular PC use and a passwordless account that is meant to be used via controller in front of a TV (ie. console-style experience). I've tried a number of different solutions, but haven't found a way to get past the "compatdata is not owned by you" error.

[sworthiness]

Agreed - this is stopping me sharing my games with my kids with their own accounts
Would love for this to get resolved

[I-Am-Xil]

Yet another comment to this 3 year old thread. Other people in my household can't play games run with proton without granting access to the sys admin user, which not only becomes an inconvenience, but also a privacy and security concern since it would mean giving other people access to first of all a personal user, but also to possibly a sudoer. This would also help mimic native games behavior.

Giving an option to grant access based on group rather than user ownership is the way to go forward with this issue.

[ChrisBoomhower]

Yep, I'm in the same boat as others. I'd love to see this resolved for the same reasons.

[couchsweetpotato]

Same here, my partner and I share the "gaming pc", and we don't have enough storage to install 100+GB like BD3 or FO76 twice, I understand the limitations because of how privileges work in Linux, but games are getting bigger and bigger, and it's not viable to install things twice anymore.

To me (not a programmer) this approach seems pretty clean and I´d like to think that its possible using symlinks for the game data while keeping the prefixes in the home folders.

I read somewhere while looking for a solution for this that sharing the installation folder would mean having to share game settings between users, but afaik that isn't true for pretty much every modern game. And when it comes to older games saving confs in the installation folder, I wouldn't consider that to be a problem because that's the intended behavior and would work in windows just the same.

[BigBrawler]

I would like to see this too.

[etyarews]

I just want /compatdata to be independent of the library. Most games save to /compatdata and this would prevent save files being shared, as weel as the issues with permission. I don't see any drawback.

Heck, this PR fixes all the issues with the current implementation.

[kamichal]

Currently facing the same issue. My kids and I finally got a super-duper gaming PC, I'm a linux pro user for over 10 years, did my best to give the shared permissions to the games storage directory, but this still raises permission issues.

No CS today, no CS tomorrow. Why are you doing it to us? It's a torture. And my son asks me if somebody better skilled than me can solve it.. Please fix it

[etyarews]

@kamichal you can do some really cursed thing where the shared library compatdata is mounted to a compatdata inside each user during log-in

It is not the proper fix, but could help you and your family

[kamichal]

I could try, but what exactly do you mean? Sounds like not a symbolic link, but some per-user mount, isn't?
So, as I understood, a mount point should be /opt/games/steamapps/compatdata and for each user, the source of the data should be /home/given_user/.local/share/Steam/steamapps/compatdata ?

[etyarews]

Pretty much. I haven't tested it yet, as I'm going to be building a shared super-duper PC during November, but I've asked around and you should create a service for each user that does this on login

This has the annoying issue of making it a nightmare if you change from one user to another(as in, Linux user) without ending that session, but hey, better than nothing.

[Rhimlock]

My Workaround to avoid bindfs:

1. create a second Steam-Library for each user (Steam->Settings->Storage). I use ~/.steam/shared

2. make sure all Library-Entries for Proton and SteamLinuxRuntime are in your first local library
   

3. create a shared folder for the users (I use /home/shared, )

• sudo mkdir /home/shared
• sudo chown :users /home/shared
• sudo chmod -R 2770 /home/shared

4. create a linked folder for common in your second library

• ln -s /home/shared/steam_common ~/.steam/shared/steamapps/common

Install games to your second Library and only the game data will be on your shared Folder. This way Proton always runs in the user-context. At least I tested it with Baldurs Gate 3 and Cyberpunk 2077.

[etyarews]

Install games to your second Library and only the game data will be on your shared Folder. This way Proton always runs in the user-context. At least I tested it with Baldurs Gate 3 and Cyberpunk 2077.

Won't this mess up cause for a steam library to work it needs the .acf files outside the common folder?

[gillius]

I am curious to know how @Rhimlock's solution works as well, right now my workaround is I have a /home/shared folder and a script that symlinks the /home/shared/steamapps/compatdata folder to a folder that exists within the user's folder, runs steam, then reverts on exit. I haven't posted it here because it needs a lot of work to be safe to use, that is there are two huge problems here around the fact that the "shared" folder is set up for 1 user at a time:

1. Steam stays loaded in the background, so if switching users I have to be very careful to exit Steam so the script terminates and cleans up the shared folder for the next user.
2. If the system crashes or script is killed for any other reason it leaves behind a mess I have to clean up in the terminal.

Of course, with extra work you could detect and fix these things with the script, use pid files or maybe systemd configuration to ensure not more than 1 steam runs at a time, etc. But I've not done that. However, Rhimlock's suggestion basically flips the idea around, rather than "share everything except compatdata", it's "share only common". But I do wonder about files like acf, and other folder I don't fully understand like workshop. It looks like shadercache would be duplicated, on my system it's only 2GB though. And it's probably better than downloading and temp folders are not shared, but there's probably still going to be issues if 2 users try to download or update the same game at the same time. Download is not likely, but auto-update could be if both users are running Steam concurrently. I noticed on Windows, it looks like if another user launches Steam, it kills the other instance, so there's probably reason for that...

[Rhimlock]

@etyarews
My second steam storage looks like this:
/home/rhimlock/.steam/shared/ (maybe bad name, since only the "common"-folder is shared)
Content from ./steamapps/

So the *.acf-Files are all in my home-folder, while the content from common is located in the shared folder.

@gillius
I tried something like what you did too.
Library as /home/shared/steamlib and use a script to change ownership to the current user, because the Proton runtimes and some files in compatdata needed to be owned by the user, not just the group. But that was quite buggy and sometimes still required sudo privileges.

As far as I can tell, you tried to link those files from your shared folder to your home-directory instead of changing the ownership.

So my solution is the opposite of yours ;-)
I don't link from the shared folder to my home folder but the other way around.

My steam-storage is the default in ~/.steam/debian-installation where all items from Proton and SteamRuntime are located.
My second steam-storage is also in my home-directory at ~/.steam/shared (see above).

And this linked common folder looks like this

(I just noticed that steam.dll still links to my wife's home-directory, but that seems to be no problem at all)

I hope this makes it a little bit easier to understand.

[etyarews]

@Rhimlock From my understanding, Steam requires the .acf files to properly recognize and import the game. Here's what I understand is going to happen:

1. Alice and Bob share the same computer, each with their own Linux user and Steam user. /home/alice/personal/steam/steamapps/commonand /home/bob/personal/steam/steamapps/common all point out to /games/shared/steam/steamapps/common
2. This means that each user has their own unique set of *.acf-Files on their `/personal/steam/steamapps directory
3. Alice downloads Alice Madness Returns, the game is downloaded to /games/shared/steam/steamapps/common. At the same time, appmanifest_19680.acf is created on /home/alice/personal/steam/steamapps
4. Bob has access to the downloaded game on the common folder, but he doesn't have appmanifest_19680.acf on /home/bob/personal/steam/steamapps. This means that his Steam will not show the game as installed.

I don't think Bob will have access to the game. I've checked here by deleting the appmanifest_19680.acf while keeping the game on /common directory and Steam couldn't tell the game existed.

[alxchnr]

@etyarews I can confirm that @Rhimlock 's solution works: we have multiple users (me and my kids) who use Steam.

1. Created a new library in my son's home: ~/.steam/shared in the Steam UI.
   His Steam library (in the UI) shows all games I made available to him by the family sharing - but nothing installed yet, as the appmanifest*.acf files are missing.

2. Linked his ~/.steam/shared/steamapps/common folder to /home/share/SteamLibrary/steamapps/common
   There the installation data of all games I installed with my own account are available.
   File-ownership-rights and access-rights are set properly there for the user-group "steam" to which all steam users on our system belong.

3. If my son now "installs" a game, Steam recognizes the available installation data, checks it and creates the local appmanifest*.acf file under ~/.steam/shared/steamapps

Now the issue is gone that he wasn't able to run games using Proton which I previously installed with my own account under /home/share/SteamLibrary

[etyarews]

@alxchnr Not sure if I understand this right, but Steam will only create the appmanifest*.acf file when your son tries to install a game that already exists on the shared library, this means he has to manually select "Install", right? This is a problem

I was pointing out is that without the files, Steam will require manual intervention to pick up the games, which is less than ideal.

[alxchnr]

@etyarews Yes, he has to "install" it manually and Steam will recognize that the installation data is already available in the shared /common folder - instead of newly downloading and installing separately.

But I also see that your scenario is quite different from mine: my son sees the available but not yet installed games in his Steam library as I made them visible to him by the family sharing option.
In your scenario Bob has no visible sign that Alice bought, downloaded and installed a game into the shared folder and probably doesn't get it shown in his library as an available & installable game(?).

[Rhimlock]

@etyarews know I understand what you meant. And @alxchnr 's explanation is correct.

I have a family group in Steam for my wife and myself and we got some games we like to share but also some that one of us wants to play but the other one does not care about. So they don't show up in the ready to play filter.
So when you install a game that the other user already installed, the Download will only verify the installed files.

[etyarews]

Yeah, while I don't love how this needs manual intervention, I think this is the ideal solution. A benefit is that since Steam is "installing" the game again, it means that a shortcut will be created for Bob

I'm also going to link the downloading and shadercache folders, as this hopefully will reduce the duplicated amount of files. Unsure about temp tho