[GH-ISSUE #69] Feature Idea: Deduped Steam Libraries #47

New issue

Closed

opened 2026-10-15 12:55:19 +00:00 by bsakaguchi · 15 comments

bsakaguchi commented 2026-10-15 12:55:19 +00:00

Owner

Copy link

Originally created by @duskmoss on GitHub (May 2, 2024).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/69

It seems likely to cause problems to use the same steam library folder for multiple clients, at least at the same time.

So something that could be useful is running dedupe remove against the container folders for various clients. If mounted on BTRFS this could save a few gigabytes in the base image and many more in game downloads.

It would also be cool if there could be a main Steam container that installs all the games and is running when any steam containers for clients are open so a new client can install by steams feature to transfer from it over the "local-network". Which in this case can be a really quick bridge between containers.

Hard part on the main Steam container part might be identifying what a client steam container has installed to then installing on the "master" container. Maybe we can just look at "steamapps" grab the ids from the list of appmanifest_.acf files and then send those to steamcmd? But I'm not sure if a headless steam manage steamcmd implements the local network transfer stuff. Perhaps with a full fledged steam client we can just copy the files in? but I'm not sure if we'd need to trigger it to recognize them and offer them to other clients somehow.

Originally created by @duskmoss on GitHub (May 2, 2024). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/69 It seems likely to cause problems to use the same steam library folder for multiple clients, at least at the same time. So something that could be useful is running dedupe remove against the container folders for various clients. If mounted on BTRFS this could save a few gigabytes in the base image and many more in game downloads. It would also be cool if there could be a main Steam container that installs all the games and is running when any steam containers for clients are open so a new client can install by steams feature to transfer from it over the "local-network". Which in this case can be a really quick bridge between containers. Hard part on the main Steam container part might be identifying what a client steam container has installed to then installing on the "master" container. Maybe we can just look at "steamapps" grab the ids from the list of appmanifest_<id>.acf files and then send those to steamcmd? But I'm not sure if a headless steam manage steamcmd implements the local network transfer stuff. Perhaps with a full fledged steam client we can just copy the files in? but I'm not sure if we'd need to trigger it to recognize them and offer them to other clients somehow.

bsakaguchi 2026-10-15 12:55:19 +00:00

• closed this issue
• added the
  question
  label

bsakaguchi commented 2026-10-15 12:55:20 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (May 2, 2024):

Not sure if this is something that we could add to Wolf or it just needs to be properly setup on the host..

I'm not sure if a headless steam manage steamcmd implements the local network transfer stuff. Perhaps with a full fledged steam client we can just copy the files in?

The steam image runs the full client, so everything should be available as is

<!-- gh-comment-id:2090883844 --> @ABeltramo commented on GitHub (May 2, 2024): Not sure if this is something that we could add to Wolf or it just needs to be properly setup on the host.. > I'm not sure if a headless steam manage steamcmd implements the local network transfer stuff. Perhaps with a full fledged steam client we can just copy the files in? The `steam` image runs the full client, so everything should be available as is

bsakaguchi commented 2026-10-15 12:55:21 +00:00

Author

Owner

Copy link

@duskmoss commented on GitHub (May 2, 2024):

It could be something that Wolf doesn't do, but its a lot of state that specifically is useful to wolf, and seems to have advantages to be tied in to its lifecycle. Integrating some sort of plan here to avoid wasted diskspace and redownloading games for each streaming device will also make users less likely to just throw a single drive in mounts and put steam library on there. But maybe that would just work well enough, it feels like it's asking for race conditions messing everything up in a multi user environment.

So for the goal of 1) reducing disk usage 2) reducing need to redownload:

1. Something needs to run "duperemove" after certain periods.

This part of the feature is fairly easy to do outside, just have a cron job that dedupes the wolf folder once a day. However it makes a lot of sense to me if if Wolf schedules it when a container shuts down, to dedupe files added during that session.

2. This one is a lot tricker to set up, and is more software than just configuration. Just running a steam client on the host doesn't do anything unless all games which will be installed by clients are pre installed there. And there's no always running steam for hosts which are fully headless. The idea here would be to have a steam container that isn't tied to a client, and some plumbing so that after clients install games in their steam containers, it installs them so that a different client won't have to download from the net again.

| The steam image runs the full client, so everything should be available as is

Right, but the steamcmd comment wasn't about a image spun up for a client. Those do already transfer from local network, and if you have Steam running on the host they will transfer from there, though not as fast as could be done between containers on a shared internal bridge.

Building on that, if wolf can have with a container that's always on, and can be scripted to install games, it could be seamless that people don't have to download games multiple times if multiple moonlight devices play the same game on the wolf server. Another thing that could potentially be scripted externally. But here there is a risk partly installed games being transferred depending on implementation Wolf doing it when a client shuts down would make it somewhat atomic.

SteamCMD is easier to script which is why I wonder if it can do the local network transfers. Another image like is spin up for clients would for sure work to serve games to the others, but I'm not sure sosohow to script it installing games. And wolf probably would need a way to connect to it's display to administer it (set it to allow all users on the local network to transfer games at least)

Been thinking about a potentially easier path for 2) even if it does have some disadvantages:

Another approach could be adding a LanCache container to wolfs network. I stopped running one at home because I had flakiness with steam deciding to bypass the container, but I hope it would be more reliable in the virtual network.Another downside is that update churn can cause extra disk space spent on no longer relevant files. It also wouldn't dedupe as cleanly as a "main" steam container approach because it stores compressed chunks and not the specific files. On the plus side it wouldn't need any sort of system to recognize what clients installed and install them on a master container. It would be a lot less moving parts, just some docker network design.

There would still be advantages to having LanCache run by wolf and not set up externally. Mostly so it can be part of an internal bridge, because networking between containers is much faster that way than on the default bridge, DNS is handled better, and wolf can ensure DNS is set on the steam containers to use LanCache without a user having to mess with their local networks settings.

<!-- gh-comment-id:2091174237 --> @duskmoss commented on GitHub (May 2, 2024): It could be something that Wolf doesn't do, but its a lot of state that specifically is useful to wolf, and seems to have advantages to be tied in to its lifecycle. Integrating some sort of plan here to avoid wasted diskspace and redownloading games for each streaming device will also make users less likely to just throw a single drive in mounts and put steam library on there. But maybe that would just work well enough, it feels like it's asking for race conditions messing everything up in a multi user environment. So for the goal of 1) reducing disk usage 2) reducing need to redownload: 1) Something needs to run "duperemove" after certain periods. This part of the feature is fairly easy to do outside, just have a cron job that dedupes the wolf folder once a day. However it makes a lot of sense to me if if Wolf schedules it when a container shuts down, to dedupe files added during that session. 2) This one is a lot tricker to set up, and is more software than just configuration. Just running a steam client on the host doesn't do anything unless all games which will be installed by clients are pre installed there. And there's no always running steam for hosts which are fully headless. The idea here would be to have a steam container that isn't tied to a client, and some plumbing so that after clients install games in their steam containers, it installs them so that a different client won't have to download from the net again. | The steam image runs the full client, so everything should be available as is Right, but the steamcmd comment wasn't about a image spun up for a client. Those do already transfer from local network, and if you have Steam running on the host they will transfer from there, though not as fast as could be done between containers on a shared internal bridge. Building on that, if wolf can have with a container that's always on, and can be scripted to install games, it could be seamless that people don't have to download games multiple times if multiple moonlight devices play the same game on the wolf server. Another thing that could potentially be scripted externally. But here there is a risk partly installed games being transferred depending on implementation Wolf doing it when a client shuts down would make it somewhat atomic. SteamCMD is easier to script which is why I wonder if it can do the local network transfers. Another image like is spin up for clients would for sure work to serve games to the others, but I'm not sure sosohow to script it installing games. And wolf probably would need a way to connect to it's display to administer it (set it to allow all users on the local network to transfer games at least) Been thinking about a potentially easier path for 2) even if it does have some disadvantages: Another approach could be adding a LanCache container to wolfs network. I stopped running one at home because I had flakiness with steam deciding to bypass the container, but I hope it would be more reliable in the virtual network.Another downside is that update churn can cause extra disk space spent on no longer relevant files. It also wouldn't dedupe as cleanly as a "main" steam container approach because it stores compressed chunks and not the specific files. On the plus side it wouldn't need any sort of system to recognize what clients installed and install them on a master container. It would be a lot less moving parts, just some docker network design. There would still be advantages to having LanCache run by wolf and not set up externally. Mostly so it can be part of an internal bridge, because networking between containers is much faster that way than on the default bridge, DNS is handled better, and wolf can ensure DNS is set on the steam containers to use LanCache without a user having to mess with their local networks settings.

bsakaguchi commented 2026-10-15 12:55:21 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (May 2, 2024):

The more I read about this the more I think this is getting outside the scope of Wolf but it's a very interesting discussion and you brought up a lot of good points, there's lots to digest so here are a few random counter points:

• RE duperemove: I don't like having to implement filesystem specific code (nor forcing such a personal choice to users), this should be scripted outside Wolf. We could easily add a pre/post session script hook to facilitate that.
• The solution of having a Steam "main" account has the main drawback that you need an account that owns all the possible games that the "secondary" accounts will need, AFAIU SteamCMD needs a valid login (that possibly bought the game already) to download/update games.
  • This really feels like a hack and easily error prone, having to orchestrate all that seems like asking for troubles..
• LanCache + Deduplication (btrfs/zfs/any other fs that supports this) seems to really be the right solution for this. With LanCache you download only once, on-demand and most importantly transparently to all clients (and not just Steam); with deduplication you avoid any wasted disk space and just share the same blocks between clients.
  • This should be setup outside Wolf, based on user preference and actual requirements; there's no one-size fits all solution for this.
  • As for the networking and internal bridges concerns this should be already possible by overriding the default docker params in Wolf config.toml (you can manually override NetworkingConfig, NetworkMode and so on already in there).
    • Besides, this is something that different users will want to tweak (ex: a LanCache somewhere in the network that might be shared with other machines/desktops or a local one in the same machine that runs Wolf)

I'd be very interested in digging further into LanCache + Deduplication even if it's just going to end up being documentation and not actual code. I always wanted to checkout LanCache ony my homelab this might be the right time to actually do it!

<!-- gh-comment-id:2091405182 --> @ABeltramo commented on GitHub (May 2, 2024): The more I read about this the more I think this is getting outside the scope of Wolf but it's a very interesting discussion and you brought up a lot of good points, there's lots to digest so here are a few random counter points: - RE `duperemove`: I don't like having to implement filesystem specific code (nor forcing such a personal choice to users), this should be scripted outside Wolf. We could easily add a pre/post session script hook to facilitate that. - The solution of having a Steam "main" account has the main drawback that you need an account that owns all the possible games that the "secondary" accounts will need, AFAIU SteamCMD needs a valid login (that possibly bought the game already) to download/update games. - This really feels like a hack and easily error prone, having to orchestrate all that seems like asking for troubles.. - LanCache + Deduplication (btrfs/zfs/any other fs that supports this) **seems to really be the right solution for this**. With LanCache you download only once, on-demand and most importantly transparently to all clients (and not just Steam); with deduplication you avoid any wasted disk space and just share the same blocks between clients. - This should be setup outside Wolf, based on user preference and actual requirements; there's no one-size fits all solution for this. - As for the networking and internal bridges concerns this should be already possible by overriding the default docker params in Wolf `config.toml` (you can manually override `NetworkingConfig`, `NetworkMode` and so on already in there). - Besides, this is something that different users will want to tweak (ex: a LanCache somewhere in the network that might be shared with other machines/desktops or a local one in the same machine that runs Wolf) **I'd be very interested in digging further into LanCache + Deduplication** even if it's just going to end up being documentation and not actual code. I always wanted to checkout LanCache ony my homelab this might be the right time to actually do it!

bsakaguchi commented 2026-10-15 12:55:21 +00:00

Author

Owner

Copy link

@duskmoss commented on GitHub (May 2, 2024):

Thanks for reading and engaging!

I don't like having to implement filesystem specific code (nor forcing such a personal choice to users),
duperemove, isn't filesystem specific it's a external utility that uses linux ioctl s that some filesystems (btrfs, xfs, in progress with zfs) support. Simply exits if the files it's pointed at don't support the ioctl.

I do like the idea of hooks and they will be useful for other stuff. I'm still tempted to say it should be something on by default for people but I can live with it not being :)

You need an account that owns all the possible games that the "secondary" accounts

mm yeah. I suppose mostly assuming it was different client devices but same steam account, but this would be a hard part. Hmm.

I'd be very interested in digging further into LanCache + Deduplication even if it's just going to end up being documentation and not actual code.

I think with Lancache even if it's just publishing a docker compose example of it would massively help people out. Running it on a different machine will be much slower without multi gig networking.

As for the networking and internal bridges concerns this should be already possible by overriding the default docker params in Wolf config.toml (you can manually override NetworkingConfig, NetworkMode and so on already in there).

I think something may still need to be done internally for dns, to make it easy to keep the traffic to the internal docker network if running one there.

I might still explore scripting the main steam container some, because I don't trust lancache to work reliably :) If it ends up feeling easy I might have you take a look and see if you want to integrate. Or just figure out how to interface it with the hooks you add.

<!-- gh-comment-id:2091502160 --> @duskmoss commented on GitHub (May 2, 2024): Thanks for reading and engaging! > I don't like having to implement filesystem specific code (nor forcing such a personal choice to users), duperemove, isn't filesystem specific it's a external utility that uses linux `ioctl` s that some filesystems (btrfs, xfs, in progress with zfs) support. Simply exits if the files it's pointed at don't support the ioctl. I do like the idea of hooks and they will be useful for other stuff. I'm still tempted to say it should be something on by default for people but I can live with it not being :) > You need an account that owns all the possible games that the "secondary" accounts mm yeah. I suppose mostly assuming it was different client devices but same steam account, but this would be a hard part. Hmm. > I'd be very interested in digging further into LanCache + Deduplication even if it's just going to end up being documentation and not actual code. I think with Lancache even if it's just publishing a docker compose example of it would massively help people out. Running it on a different machine will be much slower without multi gig networking. > As for the networking and internal bridges concerns this should be already possible by overriding the default docker params in Wolf config.toml (you can manually override NetworkingConfig, NetworkMode and so on already in there). I think something may still need to be done internally for dns, to make it easy to keep the traffic to the internal docker network if running one there. I might still explore scripting the main steam container some, because I don't trust lancache to work reliably :) If it ends up feeling easy I might have you take a look and see if you want to integrate. Or just figure out how to interface it with the hooks you add.

bsakaguchi commented 2026-10-15 12:55:21 +00:00

Author

Owner

Copy link

@duskmoss commented on GitHub (May 3, 2024):

I'm realizing the thing I'd actually more want to hack on is probably something to make reusing containers easier. I don't particularly need or want each device I connect from to have its own set of containers.

Perhaps a user based collection. Or manual selection. Any thoughts for me on forking, vs preparing a PR or pointers on where I might want to start in the code?

<!-- gh-comment-id:2092069127 --> @duskmoss commented on GitHub (May 3, 2024): I'm realizing the thing I'd actually more want to hack on is probably something to make reusing containers easier. I don't particularly need or want each device I connect from to have its own set of containers. Perhaps a user based collection. Or manual selection. Any thoughts for me on forking, vs preparing a PR or pointers on where I might want to start in the code?

bsakaguchi commented 2026-10-15 12:55:22 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (May 4, 2024):

I'm realizing the thing I'd actually more want to hack on is probably something to make reusing containers easier. I don't particularly need or want each device I connect from to have its own set of containers.

This is a valid point and I've been thinking about it for quite some time, I believe this is part of a more general feature: share sessions (aka: co-op for multiple users or as a specific case for a single user share the container between devices).

I think there are different possible approaches to this:

• Change Wolf so that it supports a notion of users and will "assign" containers to them. This will practically have to be manually configured in the config.toml or, possibly, configured at runtime over a webui
• Make a GUI that when you start a connection with the Moonlight clients will show up the list of connected/possible users (like the Netflix first page) and then let you pick the games for that user and ultimately starts and controls the app container.

Whilst the second approach might be a bit more complex it feels that it's the best way of achieving this:

• A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming
• From the user perspective you don't have to open up a browser to set things up (some Moonlight clients aren't even able to do that: xbox, switch, ...) but you have a nice and easy interface that you can interact with your joypad
• Wolf could send messages over this GUI, ex: when first downloading a game it could show the progress bar instead of a black page like it is right now

Thoughts?

<!-- gh-comment-id:2094133261 --> @ABeltramo commented on GitHub (May 4, 2024): > I'm realizing the thing I'd actually more want to hack on is probably something to make reusing containers easier. I don't particularly need or want each device I connect from to have its own set of containers. This is a valid point and I've been thinking about it for quite some time, I believe this is part of a more general feature: share sessions (aka: co-op for multiple users or as a specific case for a single user share the container between devices). I think there are different possible approaches to this: - Change Wolf so that it supports a notion of users and will "assign" containers to them. This will practically have to be manually configured in the config.toml or, possibly, configured at runtime over a webui - Make a GUI that when you start a connection with the Moonlight clients will show up the list of connected/possible users (like the Netflix first page) and then let you pick the games for that user and ultimately starts and controls the app container. Whilst the second approach might be a bit more complex it feels that it's the best way of achieving this: - A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming - From the user perspective you don't have to open up a browser to set things up (some Moonlight clients aren't even able to do that: xbox, switch, ...) but you have a nice and easy interface that you can interact with your joypad - Wolf could send messages over this GUI, ex: when first downloading a game it could show the progress bar instead of a black page like it is right now Thoughts?

bsakaguchi commented 2026-10-15 12:55:22 +00:00

Author

Owner

Copy link

@vinibutturi commented on GitHub (May 31, 2024):

• A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming

That would be really cool 🤩

If I may add my 2 cents, this is how I see it:

• Instead of having all the games showing up on moonlight, we just got one game/app which will be a launcher.
• From the launcher we could start other apps/games, manage/select users, and join sessions with another player.
• The launcher would also be responsible for calling any pre/post script we might want to hook to the apps/games

is that similar to what you're thinking or am I dreaming too much?

<!-- gh-comment-id:2141432034 --> @vinibutturi commented on GitHub (May 31, 2024): > * A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming That would be really cool 🤩 If I may add my 2 cents, this is how I see it: - Instead of having all the games showing up on moonlight, we just got one game/app which will be a launcher. - From the launcher we could start other apps/games, manage/select users, and join sessions with another player. - The launcher would also be responsible for calling any pre/post script we might want to hook to the apps/games is that similar to what you're thinking or am I dreaming too much?

bsakaguchi commented 2026-10-15 12:55:22 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (May 31, 2024):

• A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming

That would be really cool 🤩

If I may add my 2 cents, this is how I see it:

* Instead of having all the games showing up on moonlight, we just got one game/app which will be a launcher.

* From the launcher we could start other apps/games, manage/select users, and join sessions with another player.

* The launcher would also be responsible for calling any pre/post script we might want to hook to the apps/games

is that similar to what you're thinking or am I dreaming too much?

That's exactly what I have in mind, it's not a simple task, but it's definitely doable! Anyone wants to help out? 😅

<!-- gh-comment-id:2142731884 --> @ABeltramo commented on GitHub (May 31, 2024): > > * A completely independent game and user launcher so that Wolf can be focused just on the Moonlight protocol and streaming > > That would be really cool 🤩 > > If I may add my 2 cents, this is how I see it: > > * Instead of having all the games showing up on moonlight, we just got one game/app which will be a launcher. > > * From the launcher we could start other apps/games, manage/select users, and join sessions with another player. > > * The launcher would also be responsible for calling any pre/post script we might want to hook to the apps/games > > > is that similar to what you're thinking or am I dreaming too much? That's exactly what I have in mind, it's not a simple task, but it's definitely doable! Anyone wants to help out? 😅

bsakaguchi commented 2026-10-15 12:55:23 +00:00

Author

Owner

Copy link

@vinibutturi commented on GitHub (Jun 1, 2024):

That's exactly what I have in mind, it's not a simple task, but it's definitely doable! Anyone wants to help out? 😅

I would love to help, but I'm gonna need some guidance on all the tech involved.
I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me.

<!-- gh-comment-id:2143371787 --> @vinibutturi commented on GitHub (Jun 1, 2024): > That's exactly what I have in mind, it's not a simple task, but it's definitely doable! Anyone wants to help out? 😅 I would love to help, but I'm gonna need some guidance on all the tech involved. I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me.

bsakaguchi commented 2026-10-15 12:55:23 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Jun 2, 2024):

I would love to help, but I'm gonna need some guidance on all the tech involved.
I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me.

The good news is that this will likely be a separate project from Wolf, so it can be done in any language (probably not C++).
It could even be just a simple GUI program that will run fullscreen, and that will communicate back with Wolf when a selection of user+app has been made.

I have to define the requirements a bit better..

<!-- gh-comment-id:2143741730 --> @ABeltramo commented on GitHub (Jun 2, 2024): > I would love to help, but I'm gonna need some guidance on all the tech involved. > I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me. > The good news is that this will likely be a separate project from Wolf, so it can be done in any language (probably not C++). It could even be just a simple GUI program that will run fullscreen, and that will communicate back with Wolf when a selection of user+app has been made. I have to define the requirements a bit better..

bsakaguchi commented 2026-10-15 12:55:23 +00:00

Author

Owner

Copy link

@vinibutturi commented on GitHub (Jun 2, 2024):

I would love to help, but I'm gonna need some guidance on all the tech involved.
I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me.

The good news is that this will likely be a separate project from Wolf, so it can be done in any language (probably not C++). It could even be just a simple GUI program that will run fullscreen, and that will communicate back with Wolf when a selection of user+app has been made.

I have to define the requirements a bit better..

yeah, keep it as a separated project is the way to go.
What do you think about moving this conversation to discord? More convenient and we can brainstorm it further :)

<!-- gh-comment-id:2143794817 --> @vinibutturi commented on GitHub (Jun 2, 2024): > > I would love to help, but I'm gonna need some guidance on all the tech involved. > > I got 10+ years experience with ERP development (X++ language) so I'm not starting from scratch, but this is completely new game to me. > > The good news is that this will likely be a separate project from Wolf, so it can be done in any language (probably not C++). It could even be just a simple GUI program that will run fullscreen, and that will communicate back with Wolf when a selection of user+app has been made. > > I have to define the requirements a bit better.. yeah, keep it as a separated project is the way to go. What do you think about moving this conversation to discord? More convenient and we can brainstorm it further :)

bsakaguchi commented 2026-10-15 12:55:23 +00:00

Author

Owner

Copy link

@rty813 commented on GitHub (Jun 6, 2024):

My method is to mount the .steam directory. If it's just for personal use, you can use this solution.

<!-- gh-comment-id:2151594886 --> @rty813 commented on GitHub (Jun 6, 2024): My method is to mount the .steam directory. If it's just for personal use, you can use this solution. 

bsakaguchi commented 2026-10-15 12:55:23 +00:00

Author

Owner

Copy link

@a-priestley commented on GitHub (Jun 25, 2024):

my toml block for steam:

[[apps]]
title = "Steam"
start_virtual_compositor = true

[apps.runner]
type = "docker"
name = "WolfSteam"
image = "ghcr.io/games-on-whales/steam:edge"
mounts = [
    "/mnt/games:/mnt/games",
    """
/home/apriestley/.steam/steam/userdata/19414271/config/shortcuts.vdf:/home/retro/.steam/steam/userdata/1941427\
1/config/shortcuts.vdf\
""",
    "/home/apriestley/.steam/steam/compatibilitytools.d:/home/retro/.steam/steam/compatibilitytools.d",
    """
/home/apriestley/.steam/steam/config/libraryfolders.vdf:/home/retro/.steam/steam/steamapps/libraryfolders.vdf\
""",
]
env = [
    "PROTON_LOG=1",
    "RUN_GAMESCOPE=true",
    "GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*",
]
devices = []
ports = []
base_create_json = """
{
  "HostConfig": {
    "IpcMode": "host",
    "CapAdd": ["SYS_ADMIN", "SYS_NICE", "SYS_PTRACE", "NET_RAW", "MKNOD", "NET_ADMIN"],
    "SecurityOpt": ["seccomp=unconfined", "apparmor=unconfined"],
    "Ulimits": [{"Name":"nofile", "Hard":10240, "Soft":10240}],
    "Privileged": false,
    "DeviceCgroupRules": ["c 13:* rmw"]
  }
}
\
"""

The relevant bits are in the mount directive. /mnt/games contains my libraries for every platform (or no platform). The entry with shortcuts.vdf contains configs specifying any non-steam games I've added in steam on the host machine (your steam user ID will be different), and the entry with libraryfolders.vdf is the config for specifying extra library directories, such as when you might keep your titles installed on a separate storage drive like myself. The mount for the library itself is mapped one-to-one - it's identical on the host and client, as that's how the vdf files are configured.
As an extra, I have an entry there for the compatabilitytools.d directory, so that I can pass in custom tools from the host, such as ge-proton or steamtinkerlaunch.

This isn't deduplication, but it works well.

EDIT:

I also have written this guide for setting up proper block-level deduplication using bees on top of btrfs, exposing storage shares over iSCSI. For this setup, the host and client are on the same machine. Potentially, each separate wolf user can own a discrete backstore pointed at the same disk image.
It's been a while since I've experimented with this, but it came with its fair share of issues (kernel I/O faults in my case), which may or may not have been due to some faulty memory I had installed in my machine at the time. I'm betting that there are improvements to be made.

<!-- gh-comment-id:2189915940 --> @a-priestley commented on GitHub (Jun 25, 2024): my toml block for steam: ```toml [[apps]] title = "Steam" start_virtual_compositor = true [apps.runner] type = "docker" name = "WolfSteam" image = "ghcr.io/games-on-whales/steam:edge" mounts = [ "/mnt/games:/mnt/games", """ /home/apriestley/.steam/steam/userdata/19414271/config/shortcuts.vdf:/home/retro/.steam/steam/userdata/1941427\ 1/config/shortcuts.vdf\ """, "/home/apriestley/.steam/steam/compatibilitytools.d:/home/retro/.steam/steam/compatibilitytools.d", """ /home/apriestley/.steam/steam/config/libraryfolders.vdf:/home/retro/.steam/steam/steamapps/libraryfolders.vdf\ """, ] env = [ "PROTON_LOG=1", "RUN_GAMESCOPE=true", "GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*", ] devices = [] ports = [] base_create_json = """ { "HostConfig": { "IpcMode": "host", "CapAdd": ["SYS_ADMIN", "SYS_NICE", "SYS_PTRACE", "NET_RAW", "MKNOD", "NET_ADMIN"], "SecurityOpt": ["seccomp=unconfined", "apparmor=unconfined"], "Ulimits": [{"Name":"nofile", "Hard":10240, "Soft":10240}], "Privileged": false, "DeviceCgroupRules": ["c 13:* rmw"] } } \ """ ``` The relevant bits are in the `mount` directive. `/mnt/games` contains my libraries for every platform (or no platform). The entry with `shortcuts.vdf` contains configs specifying any non-steam games I've added in steam on the host machine (your steam user ID will be different), and the entry with `libraryfolders.vdf` is the config for specifying extra library directories, such as when you might keep your titles installed on a separate storage drive like myself. The mount for the library itself is mapped one-to-one - it's identical on the host and client, as that's how the vdf files are configured. As an extra, I have an entry there for the `compatabilitytools.d` directory, so that I can pass in custom tools from the host, such as ge-proton or steamtinkerlaunch. This isn't deduplication, but it works well. EDIT: I also have written [this guide](https://discord.com/channels/856434175455133727/1141892192777031701) for setting up proper block-level deduplication using [bees](https://github.com/Zygo/bees) on top of btrfs, exposing storage shares over iSCSI. For this setup, the host and client are on the same machine. Potentially, each separate wolf user can own a discrete backstore pointed at the same disk image. It's been a while since I've experimented with this, but it came with its fair share of issues (kernel I/O faults in my case), which may or may not have been due to some faulty memory I had installed in my machine at the time. I'm betting that there are improvements to be made.

bsakaguchi commented 2026-10-15 12:55:24 +00:00

Author

Owner

Copy link

@salty2011 commented on GitHub (Jan 5, 2025):

@a-priestley > thanks for the guide, will take a look, would be curious to know if you have done any changes to the various vdfs.

Just reading over this whole issue @duskmoss I dont believe there are any pending actions here today as this sorta falls outside of the scope of wolf at this stage. However there have been efforts by several others to get shared steam libraries working so that multiple copies dont exist. There are two challenges to over come, user stage not being written to the game install location. and providing a single copy of game installations. Several community members have put forward ideas that need further investigation.

I am closing this issue given no pending actions and age.

<!-- gh-comment-id:2571531150 --> @salty2011 commented on GitHub (Jan 5, 2025): @a-priestley > thanks for the guide, will take a look, would be curious to know if you have done any changes to the various vdfs. Just reading over this whole issue @duskmoss I dont believe there are any pending actions here today as this sorta falls outside of the scope of wolf at this stage. However there have been efforts by several others to get shared steam libraries working so that multiple copies dont exist. There are two challenges to over come, user stage not being written to the game install location. and providing a single copy of game installations. Several community members have put forward ideas that need further investigation. I am closing this issue given no pending actions and age.

bsakaguchi commented 2026-10-15 12:55:24 +00:00

Author

Owner

Copy link

@salty2011 commented on GitHub (Jan 5, 2025):

No further action to be taken at this stage

<!-- gh-comment-id:2571531285 --> @salty2011 commented on GitHub (Jan 5, 2025): No further action to be taken at this stage

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

beta

feat/fedora-base-images

stable

axolotlitehotfix/randomly-generated-client-id

feat/vulkan-image

ci/image-smoke-harness

nv12-producer-pin

fix/nvidia-zero-copy

fix/amd-dma-buf-negotiation

fix/joypad-input-leak

codex/party-mode-split-render

ci-fedora-images

test/gst-wld-block-linear

fix/nvidia-blackwell-zero-copy

feat/embed-wolf-den

fix/fake-udev-write-db

fix/session-runner-user

fedora-dockerfile

feat/comprehensive-display-modes

aimee/quickstart-scripts

JBailes-patch-1

dev-nix

dev-fake-uinput

dev-tracy

fix/gst_vaapi

v2024.07

v2023.06

v2023.02

v2022.11

Labels

Clear labels   

🧠 1 - 🤖 999

  

AMD

  

bug

  

bug

  

cannot reproduce

  

documentation

  

duplicate

  

easy

  

enhancement

  

enhancement

  

enhancement

  

fixed?

  

fixed?

  

good first issue

  

hard

  

help wanted

  

Intel

  

invalid

  

LXC

  

medium

  

moonlight-protocol

  

Multi GPU

  

nixos

  

not a bug

  

nvidia

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

wontfix

No labels

🧠 1 - 🤖 999

AMD

bug

bug

cannot reproduce

documentation

duplicate

easy

enhancement

enhancement

enhancement

fixed?

fixed?

good first issue

hard

help wanted

Intel

invalid

LXC

medium

moonlight-protocol

Multi GPU

nixos

not a bug

nvidia

pull-request

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

games-on-whales/wolf#47

No description provided.