Status: CURRENT — HOMELAB / UNSUPPORTED-ISH STEAM SETUP
Last reviewed: 31 August 2026
Applies to: TrueNAS SMB shares, Windows Steam clients and a separate Steam updater VMThis is how I keep most of my Steam library on TrueNAS instead of filling every gaming PC with duplicate installs. It works very well for me, but Steam does not officially document one shared SMB library being actively managed by multiple Steam clients as a supported setup. I deliberately use one VM as the updater and keep Steam from starting automatically on my gaming PC to reduce the amount of simultaneous fiddling with the shared library.
I have a lot of Steam games.
Keeping every one of them on fast local NVMe would be lovely, but apparently storage manufacturers still expect money in exchange for 8 TB SSDs. Rude.
So most of my Steam library now lives on a TrueNAS SMB share. My gaming PCs can access the same game files over the network, while I still keep a local NVMe Steam library for the games where I actually care about maximum storage performance.
The part that makes the setup especially useful is a small Windows VM whose entire job is basically:
Steam updater VM
↓
Steam stays running
↓
Shared TrueNAS library
↓
Games update in the background
Gaming PC
↓
Steam DOES NOT start with Windows
↓
I want to play something
↓
Open Steam
↓
boom — game is already updated :)I don’t need Steam sitting on my gaming PC all day downloading patches in the background. The VM babysits that nonsense for me.
Why SMB instead of iSCSI?
I actually tried iSCSI first.
On paper it looked perfect: present storage from TrueNAS as a block device, Windows sees a normal disk, Steam is happy.
The problem is that a normal Windows filesystem such as NTFS expects to own that block device. Having multiple normal Windows machines mount the same iSCSI filesystem at the same time is not what it’s designed for unless you’re using a proper clustered filesystem/setup.
That killed the idea for me because I specifically wanted:
Updater VM
+
Gaming PC
+
Sim PC / other clients
↓
same game storageSMB is file sharing, so multiple clients are exactly what it’s for. TrueNAS uses Samba for SMB and supports Windows-style ACLs and multiple users/devices. Much better fit for what I was actually trying to build.
My layout
TrueNAS
└── Steam dataset
└── SMB share
↓
├── Updater VM
├── Main gaming PC
└── Other gaming/sim PC
Each Windows machine maps the share
to the same drive letter where possible.I like using the same drive letter on every Windows machine simply because it removes another variable when troubleshooting.
1. Create a dedicated Steam dataset in TrueNAS
Don’t share the root of the pool. TrueNAS’s current SMB documentation recommends creating a dedicated child dataset for SMB rather than exporting the pool/root dataset itself.
Something like:
tank
└── steamWhen creating the dataset, use the SMB dataset preset.
Current TrueNAS uses an NFSv4 ACL for datasets created with the SMB preset. That’s what I want here because the clients are Windows machines and Steam needs normal read/write/traverse behaviour across a massive tree of game directories.
2. Create the SMB user and permissions
Create or use a normal TrueNAS user with Samba Authentication enabled. Don’t use root for SMB access.
Give that user or a dedicated Steam group the access it needs to the dataset.
For my Steam library the clients need to be able to:
- Read game files.
- Create/update files.
- Delete old files during patches.
- Traverse directories.
- Write Steam’s
appmanifest_*.acffiles.
TrueNAS has both a Share ACL and the underlying Filesystem ACL. They’re separate layers. Make sure you aren’t fixing one while the other is still telling Windows to piss off.
The ACL problem I hit
This was the annoying bastard in my setup.
I initially reused storage that had been set up more like a generic Unix dataset. Steam could see the games, but Windows started throwing permission errors when actually trying to launch some game executables.
The tell was that applying the correct SMB ACL recursively made the executables work again.
That proved the network share itself wasn’t the real problem — inherited permissions on the existing files were.
Do not make “apply ACL recursively every time Steam updates” your permanent fix. If new files keep arriving with the wrong permissions, fix the dataset/ACL inheritance properly. I eventually moved the library off, corrected the dataset as a proper SMB dataset, then moved the data back rather than continuing to play permission whack-a-mole forever.
If you’re creating the Steam dataset fresh, doing it correctly from the beginning saves a lot of moving several terabytes back and forth while questioning your life choices.
3. Create the SMB share
In TrueNAS:
Shares
→ Windows (SMB) Shares
→ Add
→ select the Steam dataset
→ enable the SMB serviceFor example, if the TrueNAS hostname is truenas and the share is called steam:
\\truenas\steam4. Map it in Windows
On the gaming PC and updater VM, map the SMB share to a drive letter.
For example:
S: → \\truenas\steamYou can do that through This PC → Map network drive, or from a command prompt:
net use S: \\truenas\steam /persistent:yesWindows will use the credentials you supply/store for the TrueNAS SMB account.
I prefer mapping the drive before Steam starts. If Steam launches before Windows can see the network library, it can decide the storage has vanished and your entire library suddenly looks uninstalled. The files are usually still there; Steam is just having a moment.
5. Add the network library to Steam
Current Steam uses the Storage Manager:
Steam
→ Settings
→ Storage
→ Add Drive / +
→ Let me choose another location
→ select S:\SteamLibraryIf the library already contains games, Steam should discover the existing installations once the library folder is added.
Valve’s support documentation also recommends re-adding an existing library through Storage Manager if installed games suddenly appear as uninstalled.
My updater VM is the bit I really like
I have a small Windows VM pointed at the same Steam SMB library.
Steam stays open on that VM and its job is basically to watch the library and keep games patched.
For every game I care about keeping ready, I set:
Game
→ Properties
→ Updates
→ Automatic Updates
→ High Priority - Always auto-update this game before othersYes, I went through and set the games to High Priority. Yes, it was tedious. No, I don’t particularly want to do it again 😂.
Steam officially describes that setting as keeping the game at high priority so it auto-updates before other games.
The VM isn’t there to play anything. It’s a glorified game-patch babysitter.
Steam does NOT start with my gaming PC
This is the other half of the workflow.
On my actual gaming PC:
Steam
→ Settings
→ Interface
→ Run Steam when my computer starts
→ OFFValve still officially provides that startup toggle.
I don’t need the gaming PC sitting there all day checking a library that the VM is already maintaining.
When I actually want to play:
Turn on gaming PC
↓
SMB drive maps
↓
do normal PC stuff
↓
decide I want to play something
↓
open Steam
↓
shared library appears
↓
game is already patched
↓
boom :)That’s the whole reason I like this setup. The updater VM does the boring waiting while the gaming machine only runs Steam when I actually want Steam.
A warning about multiple Steam clients
This is the unsupported-ish part. Steam does not document a single SMB Steam library being concurrently managed by several Steam clients as a supported storage architecture.
The shared directory contains not just the game data but also Steam metadata such as:
steamapps/
├── common/
├── downloading/
├── shadercache/
└── appmanifest_123456.acfCommunity reports show that two Steam clients can disagree about or rewrite the shared appmanifest state, making games appear to require another update or disappear/reappear.
My way of reducing that mess is to give the updater VM the update job and not use the gaming PC as another always-running updater.
I also don’t deliberately kick off updates to the same game from two clients at once. Multiple machines trying to be clever with the same files is exactly how a nice simple idea turns into a Sunday afternoon repair job.
Local NVMe still has a job
I don’t force every single game onto the NAS just because I can.
My main gaming PC still has a local NVMe Steam library for FPS games and anything where I want the lowest possible storage latency or where a particular game simply behaves better locally.
Everything else can happily live on the big NAS pool.
That gives me:
Local NVMe
→ shooters / demanding favourites
TrueNAS SMB
→ giant bulk Steam library
→ older games
→ single-player games
→ games I want installed but don't play every dayIt’s not about proving a NAS is faster than NVMe — obviously it isn’t. It’s about not buying absurd amounts of local flash storage for games that spend 99% of their life doing absolutely nothing.
What about performance?
My network is 2.5 GbE, so sequential throughput from the NAS is perfectly respectable for a lot of games.
The bigger difference compared with local NVMe is latency and random I/O, not simply the headline link speed.
Some games load a mountain of tiny files and care more than others. If a game feels shit from the network library, I don’t spend three hours trying to win an argument with physics — I move that one back to NVMe.
Steam’s official alternative: Local Network Game Transfers
Valve does have an officially supported feature for moving game installs and update files between Steam machines over the LAN: Local Network Game Transfers.
That’s a really good option if your goal is:
PC 1 already has game
↓
PC 2 installs game
↓
Steam copies most/all available data over LAN
instead of downloading it again from the internetMy setup solves a different problem. I don’t want another full copy on every machine — I want most of the games to live centrally on the NAS.
If the SMB-library weirdness ever annoys you, Valve’s Local Network Transfer feature is the much more conventional fallback.
If Steam suddenly says every game is uninstalled
First, do not immediately start reinstalling 3 TB of games.
Check:
1. Is S: actually mapped?
2. Can Windows open S:\SteamLibrary?
3. Does S:\SteamLibrary\steamapps still contain the appmanifest files?
4. Does Steam → Settings → Storage still list that library?If the files are still there but Steam forgot the library, re-add the existing library folder through Storage Manager. Valve documents this as the recovery path for games that appear uninstalled even though the data still exists.
If a game EXE won’t launch from the share
This is where my original TrueNAS ACL problem showed itself.
If Steam can read/download the game but Windows fails opening executables or newly updated files behave differently from older files, inspect the TrueNAS filesystem ACL and inheritance.
For an SMB dataset, make sure the SMB user/group has the intended read/write/traverse permissions and that new files/directories inherit the correct ACL.
TrueNAS’s current SMB documentation distinguishes the SMB Share ACL from the dataset’s Filesystem ACL. Both can affect whether the Windows client actually gets the access you thought you gave it.
Would I do it again?
Yep.
iSCSI was neater when I was thinking about one Windows machine. SMB became the obvious choice once the requirement changed to one large library shared between several machines.
The updater VM is what turns it from a storage experiment into something I actually enjoy using.
VM:
"Don't worry mate, I downloaded the 87 GB patch."
Gaming PC:
"Cheers."
Me:
*opens Steam and plays the game*No giant local library on every machine, no Steam running on my desktop when I don’t need it, and far less of the “sweet, I have an hour to play — here’s a 46 GB update” experience.
Is it the most normal way to run Steam? Absolutely not.
Does that appear to have stopped me anywhere else on this website? 🙂