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.

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.

@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".

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.

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.

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.

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

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.

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

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.

I would like to see this too.

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.

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

@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

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 ?

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.