-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared Game Libraries #83
Comments
This is all very interesting and I should definitely look further into it, the arch wiki entry is a nice starting point. Am I right in thinking that this isn't really a docker specific feature? Because I saw this but it doesn't apply here since you are just manually mounting from inside the container. I have to wrap my head around it and I'm not sure how the directory tree should be managed (probably needs some proper setting in the
Steam will generally store most of his stuff under
so that each app will have a common overlay in a known location? |
Yeah there are a few ways to approach this, but to me I would have some configuration within the config.toml where you would define global settings that apply to all users. Within this section I would have a library definition that would
The default for this could be '/etc/wolf/overlay/Steam' , and agree this would mean each app would have a common overlay so that duplication of game libraries does not occur and avoid potential locking issues when multiple users are accessing the same games. Going of my previous Wolf setup on unraid the ~/.steam was being persisted outside of the container under "../wolf//Steam/" although not sure if thats something by default or if I set it up that way. |
Hi! |
hey @lukaszzyla , thats interesting. definitely going need more info. however the problem you are describing is not related this feature exactly. When setting to common it results all clients referencing same folder. This useful if there is only one user of wolf, but if you have multiple users at the same time.... this is where this proposed solution comes in. The idea is to have the steamapps folders be accessible to multiple users at the same time. Could I suggest you reach out on the discord channel or log an issue for this... When you do can you attach your wolf logs so we can get sense of whats occuring. |
I am sharing a SteamLibrary in a less sophisticated way than what is being described in this change request. In my config.toml, I added the following to the steam app.runner: mounts = [ '/mnt/games:/mnt/games:rw', '/mnt/shared:/mnt/shared:rw' ] one of these mounts is a local drive, and the other is a nfs share. When I launch a steam container for the first time, I go into settings> storage, and navigate to the 'SteamLibrary' directory in both of these mounts and add them. As far as I can tell, this method is working. I can launch the same game on 4 different containers logged in with 4 different steam accounts, however I will admit that the game doesn't always launch on the first try, or the second. If the game hangs while trying to launch, i can kill the container from the moonlight client and try again. eventually it will work. I am not sure if the reason for the failed launches is because of the shared files (e.g. file locks), or something completely unrelated, like issue #151. Presumably the suggestion to have a read-only mount as well as a write mount that merges with the ro would suggest that there is something flawed with simply mounting the SteamLibrary as rw, so I wanted to share my findings. |
With the way wolf currently works when having multiple uses, each user end up installing their own copy of a game. For illustrative purposes we have User1 and User2 (i realise wolf currently splits this out based on client unless you make changes in the config).
The user data would be stored in
/wolf/user1/.....
/wolf/user2.....
And for each user would have their copy of the game installed.
The issue with this is that results in excessive storage, additional downloads unless cached etc.
After doing some research into docker I did find a potential solution that may work. Within docker when binding folders it possible to create an overlay and that layer write changes else where. So in theory we could do this (using a simple dir structure to explain the concept)
[CONTAINER HOST]
/games/steam/{installed games}}
/wolf/user1/steam
/wolf/user2/steam
[CONTAINER]
lowerdir = /mnt/shared-steam/ (read-only)
workdir = /mnt/user-steam/ (RW)
When launching the docker container this would look like
Now within the container you'll see all installed games from the hosts /games/steam but changes would be written into /wolf/user1|2/steam, this is possible by leveraging the overlay features outlined in the last part of the command
In addition could have a 3rd container that is responsible for pre-populating /games/steam and also maybe schedule merging game installations that a user does by moving installed games from their profile into the /games/steam dir (although that may be somewhat of a challenge)
The text was updated successfully, but these errors were encountered: