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.

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

1. 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.

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?

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

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

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

@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

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

@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(?).

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

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

I've switched to the method mentioned by @Rhimlock https://github.com/ValveSoftware/Proton/issues/4820#issuecomment-2569535495. Some notes:

1. It's better than my solution in that once you set it up, you don't need any launch scripts with shaky re-linking of files.
2. I've not encountered an issue yet but I have fears of multiple steam clients running and one of them tries to update the game while the other Steam is running and maybe it might try to update it too. I know on Windows Steam is globally single instance even though the storage is shared.
3. I can confirm that the games don't show up as installed for the other users due to the unshared acf files, but if you install it doesn't download it again and shares space, which is the point. It has the pros already mentioned by @etyarews that it creates the desktop shortcut for you. The con is that you don't know the game is installed but in practice that is not an issue since you know who is playing what.
4. Uninstalling does not work properly. I tested this by temporarily removing the game folder in shared but leaving the per-user acf intact. Steam thinks it is installed and if you try to run it you get an error of missing executable, which is reasonable enough. What is odd is when I restored the folder (while having Steam closed just in case), Steam re-downloaded the entire game even though the content was there.
5. I tried sharing the Steam Linux Runtime and Proton and it doesn't work. I don't know why, but it doesn't, so you do have to follow Rhimlock's advice and have 2 libraries and probably you need to watch out in case any new versions get installed in the shared library.
6. This is a bug I've seen unrelated to sharing, but I can't actually delete a library. It disappears from the UI, but it reappears after exiting and restarting, if the folder exists. As a result, I had to rename my shared folder because Steam was seeing my "used" copy with symlinks as well as the shared copy and I'm sure had I tried to launch something it would get confused.

In summary, it works, but it's not "production-ready" in the sense it requires some baby-sitting. Uninstalls don't work and I still have fear if someone keeps steam running in background on locked screen and you switch users and have multiple steam running, which is easy to do since it stays in system tray. I manage this by always trying to sign off and/or exit Steam explicitly, but I can't say the same for my kids. However, for my use it's a lot better than the alternative of multiple downloads of 100+ GB games.

To share properly on Linux some system daemon or lockfiles to prevent concurrent update/install/uninstall operations, as well as per-user compatdata, and to be really user friendly, some UX to set up the shared folder. That said, this is a Proton GH and not Steam so changes would be needed in both to support.

A bigger issue with @Rhimlock method that I'm facing is that, untill every user has installed a game, you cannot mod it. When a user "installs" a game, Steam verifies the installation if it is already installed, if the game is modded then it un-mods it

I recently tried to help a friend who was trying to migrate from Windows with this exact issue. They ended up staying on Windows because Proton games just wouldn't work for them.

I think Steam and Proton (wine) could achieve the desired goals with only some minimal changes.

• Avoid duplicate download / storage
• Secure / validated storage
• Compatibility with silly games that write into their install directory / modified games

Regarding secure / validated storage, it makes the most sense to add a dedicated local account that is designated as trusted. This could be per steam user. Said account might be a parent / admin's personal gaming account, or it might be a dedicated user (E.G. uid=1099(steam) gid=1099(steam)). The account's configuration could be configured to 'share games via GROUP' (pick a group for setegid() / setresgid() ).

• Steam config to enable shared games + set (read only) group for access / effective GID (setegid() / setresgid())).
• Steam config to pick one (or more) 'trusted users' who's game caches are also checked.
• Steam configs to set default download location for Compatibility tool and game cache (can be the same directory or different)
• Create a UID subfolder owned by the current user as the first path within the storage cache E.G. /opt/Steam/1099/
• Have a write-able FIFO (or localhost socket) in the storage hive for 'sharing' users to request steam ID installs. (denial of service is at best download / storage, but the user enabled this)
• When installing a game or compatibility tool that a trusted user has installed, replicate the folder structure, try to hard link, then fall back to symlink, the files. Local over-writes should unlink / replace the files if not done in an inane way...
• Offer a UI option to 'make own copy' of the game that fully copies (locally) instead of just hard/sym linking.
• Verify Files might need a small modification to report that (if <=10 listed files or 'at least X files differ') and ask if the user would like to clone + repair download. (it might be worth allowing the steamd running as the trusted user to do this over the FIFO/localhost socket)
• Compatibility tools would be handled just like the games, and every user's PFX folder could symlink (as current) to their storage folder's hard/sym linked copy of the trusted files.
• There might be a setting that requires installs / requests only via other accounts (the trusted user or a not-child account).
• Accounts managed via parental controls might have settings locked / managed by the parent/admin account.

None of this should require extensive re-writes. Local storage that lacks a UID folder within the storage area would be easy to detect as the 'old layout' and converted with a simple folder creation and relocation of existing folders. On not-unix-like platforms the UID could be replaced by current username instead. The same policies would improve the security practices on those platforms as well.

Just commenting to say I need a solution for this as well. Would be lovely if Proton has an option to use user-specific steam_compat_data_path so my two sons can make use if the games I've already installed on my user.

I encountered a similar pfx not owned by you error when trying to run Red Dead Redemption 2 on Ubuntu, using a Steam installation on an NTFS drive originally set up from Windows. While my setup (Windows + Linux with a shared NTFS drive) differs from the multi-Linux-user scenario here, I’m sharing this in case it helps others facing NTFS-related permission issues, as these seem to be redirected to this issue.

The solution for me was remounting the NTFS drive with appropriate permissions and fixing the ownership of the Wine prefix directory. I’ve detailed the steps in this blog post: Fixing 'pfx is not owned by you' Error for Red Dead Redemption 2 on Ubuntu.

Hopefully, this is useful for Windows+Linux users with NTFS drives. Let me know if this is off-topic, and I can remove or adjust it!

It would be great if this issue could be given some love by Valve.

Also requesting this - this is the only blocker keeping me from using Linux for gaming.

While I think sharing is a huge feature to move to Linux, and I've been using the technique described earlier, there might be a "better" way, and that is to use a filesystem like btrfs which supports de-duplication so that even though Steam creates the files many times, the physical disk space used is not more. Has anyone tried this as a workaround? It still seems that in this case there are some limitations:

• You'll have to download the software once per user
• The de-duplication process seems to not be instant, therefore you need appropriate empty space to download then space is reclaimed by the background de-dupe over time

I have a Windows 10 machine that is used as a kids gaming machine with 3 users that can't upgrade to Windows 11. The workaround discussed earlier is hard to set up and is quirky especially with Proton runtimes, but I'm using it today on my Kubuntu desktop. My thought is to try CachyOS with btrfs to mitigate the triple Steam client and game install duplication. I have gigabit fiber so I can tolerate the triple download issue. And if it works, switch from Kubuntu to CachyOS on my main machine.

Has anyone tried this in practice and does it work effectively? Trying it out unfortunately is a sort of one-way street as I don't have enough space to dual boot that Win 10 machine.

@gillius

No, that doesn't work. Deduplication on BTRFS is done manually, after you already have files. This is called out-of-band/offline deduplication.

This means that you need to write multiple times to the disk, you are wasting the lifespan of the device significantly. And you always need to keep an available space of the size of the biggest game you own, probably double of that.

Furthermore, the deduplication process isn't instant, not only do you need to keep doing it occasionally, but you can't really automate it, for fear that it might trigger when you don't want. Depending on how much you need to dedup your system will temporarily struggle a bit.

I recommend doing Deduplication anyway because it saves a huge amount of space on proton prefixes/compatdata. You could also dedup your /home across users and the space saved will be significant. I've done it and it saved 40gb.

But I do not recommend using dedup as a way to bypass Steam Library limitations

@etyarews yes, I understand the dedupe is not instant, the data will be written once then space will reclaim over time. What I've been reading is some methods can do the dedupe incrementally. And you are saying I might not be happy with the load that puts on the system, so I might have to experiment with that. Large games are installed rarely (like monthly or less), so I may still get away with manual dedupe.

I also understand that an amount of free space equal to the largest game to be installed is required. But I have 512 GB SSD, let's say games are about 50 GB each, so we all want to play the game, it will write 150GB to disk but it will over time reduce to 50GB (approx, because there will be some deltas in compatdata for save games). That's still a 100GB savings even though I needed 150GB temporarily.

I'm not too worried about the write load. It's a shame to write an additional 50GB, but SSD endurance is in 100s or 1000s GB/day ratings and a gaming machine is way more read driven and not a write heavy workload like server or database.

The biggest problem I have with the symlinks is that it just seems to be too brittle, Steam doesn't always like to install the runtimes in the shared library and sometimes if it does I get errors revolving around file ownership even if I use sticky bits. It also doesn't handle if a user locks screen and another user logs in and starts up Steam, now there are two instances in the same folder and if it tries any updates it can cause issues. I'm not sure I understand all of the cases, and maybe it's fixable, but it's definitely not stable. The thought on BTRFS dedupe is that from a process perspective, everyone has their own disk, so it's "guaranteed" to function "normally", with the drawbacks mentioned, plus what you mentioned:

• Wasted network bandwidth
• Need to keep extra available space to install a game "already installed"; dedupe is not instant
• System load may be unacceptable while dedupe runs / might not want to schedule automatically

I don't know much about subvolumes yet, if that can mitigate some of the issue with dedupe so you don't have to scan the whole FS.

Even with the limitations, it still seems like it's worth a try over the symlink method. Obviously, I agree the best solution is for Steam to fix this so it works at least as well as Windows, but until that happens.... That's another concern with the symlink method is if Steam updates things, if it will break anything.

What is your recommendation then @etyarews? You still prefer the symlink approaches over dedupe even despite the limitations documented already in this thread?

@gillius The issue is that you need to have the free space of at least double the game you want to install.

Let's say you have 3 users and want to install a 50gb game, but you only have 100gb of free storage on your 512gb drive: You install the game on User1, install on User2, and it all "took" 100gb of space. Do the dedupe and you gain back 50gb now. You install on user3, and it took another 50gb, you dedupe again, and you gain 50gb again.

Overall you now have 50gb of free storage, but the biggest game you can install is 25gb at most, otherwise you cannot install the same game to other users because dedupe requires a copy to be existing before it dedupes.

I do use the symlink approach and haven't got any issue whatsoever. Each user has three steam libraries:

/home/USER1/.local/share/steam - Default Steam Install, Proton and Steam Runtimes are installed here
/games/USER1/Personal - Sorta of a personal stash of games, it's usually used for games where one user wants certain mods, but another doesn't. Each one have their own copy with different mods.
/games/USER1/Shared - This is the one with heavy symlinks

Alright, so let's look at /games/USER1/Shared: It has the usual steamapps folder, let's see how it works we see how it works:

/games/USER1/Shared/steamapps/common -> /games/SHARED LIBRARY/Steam/steamapps/common
/games/USER1/Shared/steamapps/downloading -> /games/SHARED LIBRARY/Steam/steamapps/downloading
/games/USER1/Shared/steamapps/shadercache -> /games/SHARED LIBRARY/Steam/steamapps/shadercache
/games/USER1/Shared/steamapps/temp -> /games/SHARED LIBRARY/Steam/steamapps/temp
/games/USER1/Shared/steamapps/compatdata -> /games/USER1/Personal/steamapps/compatdata

Every folder is being symlinked to the respective SHARED LIBRARY folder. Except compatdata, that one is symlinked to their Personal library /games/USER1/Personal

Now, on the /games/USER1/Personal/steampps folder, we only have two symlinks:

/games/USER1/Personal/steamapps/downloading -> /games/SHARED LIBRARY/Steam/steamapps/downloading
/games/USER1/Personal/steamapps/shadercache -> /games/SHARED LIBRARY/Steam/steamapps/shadercache

downloading and shadercache are symlinked to the shared library, so all users have the same shadercache and downloading status, which should at least keep Steam from downloading the same game twice, and should help the madness that is shadercache from going out of control (it still goes out of control).

Now, here's the problem: The entire /games folder and subfolders need to have permissions for all users, including new files. I did that by adding all users to a group called gamers and setting it up like so:

sudo chown -R root:gamers /games
sudo setfacl -R -m g:gamers:rwx /games
sudo setfacl -R -m mask::rwx /games
sudo setfacl -R -d -m g:gamers:rwx /games
sudo setfacl -R -d -m mask::rwx /games

However, wine really wants the prefixes to be owned by the person who is executing it, so you need to make it so that each compatdata is owned by a specific user, basically you need to undo what you've done on the previous step on only the compatdata folder.

sudo chown -R user1:user1 /games/USER1/Personal/steamapps/compatdata
sudo setfacl -b -R /games/USER1/Personal/steamapps/compatdata
sudo setfacl -m d:group::--- /games/USER1/Personal/steamapps/compatdata

sudo chown -R user2:user2 /games/USER2/Personal/steamapps/compatdata
sudo setfacl -b -R /games/USER2/Personal/steamapps/compatdata
sudo setfacl -m d:group::--- /games/USER2/Personal/steamapps/compatdata

sudo chown -R user3:user3 /games/USER3/Personal/steamapps/compatdata
sudo setfacl -b -R /games/USER3/Personal/steamapps/compatdata
sudo setfacl -m d:group::--- /games/USER3/Personal/steamapps/compatdata

I barely understand permissions and I pretty much only have a vague understanding of what each command is doing, but hey, it works. I do recommend you writing this list of commands down because if you ever needed to copy a compatdata folder to another user, you need to re-run all of this

@etyarews thanks for that, I will have to consider it when moving the new system over. Right now I only try sharing the common folder. And I've used sticky bit and not used setfacl. Like you I also faced issues with Wine wanting the prefixes owned by the executing user.

This was my biggest hurdle when ditching Windows and moving over to Linux. I found it most practical to format a disk as btrfs, then use bees for deduplication. Current solution is working really, really well once I throttled it right down. I just wrote up a quick guide.

I tried messing around with symlinking off the game files and leaving compatdata but always ran into issues managing game installs and updates across all the users.

Why is this not solved already???

Please tell me why I am dumb in assuming the obvious answer is to just have the compatdata NOT SAVED IN THE SHARED DRIVE SPACE, and instead SAVED IN THE USER HOME DIRECTORY, regardless of where the game is installed. Make it a setting or option if needed so anyone complaining has the choice.

Just make this happen already, seriously - the number of absurd overly complicated workarounds floating around is straight bonkers!

It is absolutely insane to me that this level of manipulation and set up would be needed for what should be assumed to 'just work', and does on Windows.

https://github.com/thojo0/steam-multiuser-compatdata-fix

. I found it most practical to format a disk as btrfs, then use bees for deduplication. Current solution is working really, really well once I throttled it right down. I just wrote up a quick guide.

For reference: This is the guide that solves this using btrfs.

And another backlink (especially for all users using Bazzite – an Atomic distro specifically made for gaming): here the "same" thread about the same issue. (Current Bazzite docs part about this)

. I found it most practical to format a disk as btrfs, then use bees for deduplication. Current solution is working really, really well once I throttled it right down. I just wrote up a quick guide.

For reference: This is the guide that solves this using btrfs.

And another backlink (especially for all users using Bazzite – an Atomic distro specifically made for gaming): here the "same" thread about the same issue. (Current Bazzite docs part about this)

Thanks for adding my link. When I tried my message got marked as spam and deleted. I'm no expert but I hope it helps.

It has been 5 years since this issue was first reported here. This is a significant road blocker for the adoption of Linux on multi-user setups.

Even on setups where there are multiple Steam users but a single Linux user, like the Steam Machine and Deck, this decision causes trouble as save data ends up being shared between them.

A very easy solution would be for Proton to just separate compatdata by Steam User IDs.

. I found it most practical to format a disk as btrfs, then use bees for deduplication. Current solution is working really, really well once I throttled it right down. I just wrote up a quick guide.

For reference: This is the guide that solves this using btrfs.

And another backlink (especially for all users using Bazzite – an Atomic distro specifically made for gaming): here the "same" thread about the same issue. (Current Bazzite docs part about this)

This falls squarely in the "absurd overly complicated workarounds" territory. Easily argued to not actually solve anything but sidestep the issue.

This is a Steam problem, not a filesystem configuration & management problem. Or if pulling hairs, a wine problem that steam adopted. Either way Steam needs to fix it.

BTRFS deduplication is not a solution:

1. It is offline, it is done after the space is already taken. You might have 200GB of storage free, but if you want to download a 120gb game, you cannot do it with dedup, as it needs to download two copies of the game (240gb in this example) before it shrinks to 120gb due to dedup
2. If you have a bunch of files that need to be dedup, the system might struggle for a couple of seconds while it tries to figure out what to do, so it really shouldn't be done automatically.

I will heavily disagree with @kisak-valve : This is not a wine issue per se. Even if wine allowed prefix data to be shared between different users, the issue would remain that Steam/Valve/Proton is writing data to the Steam Library without a per-user solution, even if fixed upstream, this would mean that save data is shared between users. Yes, separating compatdata would officially increase the storage taken by Steam, and it would mean game configuration data would need to be redone on each user account, but it would bring a more streamlined "Console-like" experience where save data is not shared. Right now the save data separation is up to the developer, or for the Steam Cloud, which is not ideal and can have issues.

The decision to store prefixes on the library without even a separation between users causes so many troubles and issues that it is unbelievable how the severity of this issue hasn't been more acknowledged.