Skip to content
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

Open
salty2011 opened this issue Jul 2, 2024 · 5 comments
Open

Shared Game Libraries #83

salty2011 opened this issue Jul 2, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@salty2011
Copy link
Contributor

salty2011 commented Jul 2, 2024

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

#USER1
docker run --name steamapp_user1 --privileged \
  -v /games/steam:/mnt/shared-steam:ro \
  -v /wolf/user1/steam:/mnt/user-steam \
  -it steamapp /bin/bash

docker exec -d steamapp_user1 /sbin/mount -t overlay overlay \
  -o lowerdir=/mnt/shared-steam,upperdir=/mnt/user-steam,workdir=/mnt/user-steam \
  /games/steam

#USER2
docker run --name steamapp_user2 --privileged \
  -v /games/steam:/mnt/shared-steam:ro \
  -v /wolf/user2/steam:/mnt/user-steam \
  -it steamapp /bin/bash

docker exec -d steamapp_user2 /sbin/mount -t overlay overlay \
  -o lowerdir=/mnt/shared-steam,upperdir=/mnt/user-steam,workdir=/mnt/user-steam \
  /games/steam

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)

@ABeltramo ABeltramo added the enhancement New feature or request label Jul 18, 2024
@ABeltramo
Copy link
Member

ABeltramo commented Jul 18, 2024

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 config.toml). Currently we do something like:

/etc/wolf/<user_id>/Steam:/home/retro/

Steam will generally store most of his stuff under ~/.steam. We'll then mount an overlay fs somewhere else but where would that live in the host? Something like

/etc/wolf/overlay/Steam

so that each app will have a common overlay in a known location?

@salty2011
Copy link
Contributor Author

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

  • define library locations on the host
  • the container this library applies to, as may need similar config for things like Emulation Station etc

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.

@lukaszzyla
Copy link

Hi!
I have issues trying to use the way described in quickstart for wolf.
First of all in config.toml I only have one entry for paired clients, even though I have paired 2 already.
I did the recommended solution to change the folder name there from number (10897384724) to "common"
When i tried accesing steam via moonlight for the first time from my pc and also android phone as a second user - I had steam installed and I did connect to the same common apps - I was downloading a game and on both devices I could see this game being downloaded.
But then I came to another location with another network and suddenly it stopped working - wolf created another app_state_folder for my already paired pc and I had to start everything from scratch (updating steam, logging into it and downloading game again).
When I moved contents of previously configured "common" folder to a new numeric folder that appeared after connecting from new location - everything was working, but this is very labour intensive method to move files and deal with config.toml every time I want to just access my profile and its games/progress.
I think this is one of the most important functionalities to work on at the moment and would be very happy if someone agrees.

@salty2011
Copy link
Contributor Author

salty2011 commented Aug 21, 2024

I moved contents of previously configured "common" folder to a new numeric folder that appeared after connecting from new location - everything was working,

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.

@mikewalshchicago
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants