DISK WRITE ERROR when downloading to a network drive on linux

[Rustie]

At some point recently, all downloads started failing when I point them at a library on my samba network share with the message "DISK WRITE ERROR". This is strange, since the disk is definitely writable - I can make files on it manually and steam does actually create a directory for the game, although it stays empty. Furthermore, if I install the game on a local disk first and then move it to the library on the samba share, it works just fine. I tried creating a fresh library on there, but the issue persisted.

I don't really know when this started happening, but I tried switching off the beta and it still didn't work. It's possible that it's an issue with my system configuration, though I doubt it because I didn't make any significant changes to it lately, apart from a bios and kernel update, neither of which seem likely to cause this kind of issue. The nas also didn't see any changes in a while, plus a library on it works fine under windows, so that's probably not the culprit either.

I'm running ubuntu 20.04 with kernel 5.8.5. The share is mounted as cifs.

This wouldn't be quite as annoying if steam let me move the games to the local drive to update them and then back, but it won't unless the game is already updated... I'm now stuck with either having to reinstall the games to update them, or just not being able to play them because they need an update...

[Rustie]

I have a couple updates:

I tested this on my laptop now, and it doesn't work there either...

Then I tried making an nfs share instead and download onto that and that worked perfectly fine, so it's probably an issue with cifs specifically...

I think I'll try mounting that same library as nfs and see if that works, though that will take a bit of effort. It would be an acceptable workaround for me if it does work though.

[kiseitai2]

This is still an issue. Like you, I moved to nfs with great success.

However, I got the Steam Deck, but it lacks nfs-utils in the image, so I had to go back to my samba share. I now have this issue on the Steam Deck. Hopefully, Valve sees this thread and my recent thread and figures out what might be wrong.

[Mice-stro]

i've been bugtesting this for about 2 weeks solid (having the same issue on non-beta steam) it's absolutely fine with transferring and validating files from a local (to you) disk, but it fails at validating *new data* from outside your current network. i don't know why this is, but it's *only* validation that's the problem, and usually towards the end.
specs of my nas is a 5700G with 10x4TB HDD's (20GB high-speed cache), it shouldn't be bottlenecking at all, and i've been polling it using ssh. this is the only program i have issues with, and only when pushing data to it (the nas). increasing the cache size (from 4GB) helped for smaller titles, but it looks like steam just... bails, if the connection drops for even a second, then fails to validate a half-validated game after the fact. (which now makes me think it's udp and not tcp... after some "glance googling" udp does a bit of the frontend searching of smb sharing, before using tcp to initiate transfers, which means filenames may be getting dropped?)

[Mice-stro]

oh, something i should add to this, it's only smb that's the issue here, not the os or anything else. i'm running windows 10, and all drives are new. iscusi may work, but then again it's iscusi.

[Jacob]

I am running into the same problem and have not found a solution.

[dagelf]

So... I had the same problem with NFS. But even better than "discovering" or "verifying" files, there's a great workaround, that's much faster. Here's what I did. Maybe you can skip the first few steps, let us know. But I'm doing this to save on downloading/copying/verifying time from now on:

Map a brand new blank folder. I used NFS, but I'm fairly sure SMB (normal Windows file sharing) will work and might be faster.
Map it, eg. net use \\storagebox\steam1 s:
Then go to Steam, Steam menu top left, Settings, Downloads, STEAM LIBRARY FOLDERS button. Then right arrow top right until you see the (+) button. Click it and add the drive you mapped (S:) in my case.
Then I downloaded a small game, and noticed that the only things left afterward is under steamapps/ an appmanifest_nnnn.acf file, hidden, and the game directory under steamapps/common.
Then I removed the drive from the STEAM LIBRARY FOLDERS.
now I went onto the storage server, and made a directory junction:
cd steam1\SteamLibrary\steamapps\common
mklink /j "Counter-Strike Global Offensive" "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive"
(ln -h under Linux)
Then I looked for the correct appmanifest_nnn.acf file, (you can edit it with notepad to see which one it is), and I copied that over to \steam1\SteamLibrary\steamapps
Then I added the directory back under STEAM LIBRARY FOLDERS and voila, CS Go just shoed up and ran just fine!!

You probably don't even need to use junctions or hard links, other than if your games on storagebox is not in a folder called SteamLibrary, but say it's in Steam, then you just go to inside Steam in the command prompt, and make a junction like:
mklink /j SteamLibrary .
(or in linux ln -h . SteamLibrary)
(Now you can go into Steam\SteamLibrary and the steamapps folder will be there)
So if you just map that, say to drive S:, and you add S: inside STEAM LIBRARY FOLDERS, all the games should just show up!

So instead of waiting for verification, etc. all it takes is just one directory junction!

(If you get permission denied errors, just open CMD with CTRL+SHIFT+Click or "Run as Administrator)

Now, the main issue you are likely to run into is if multiple steam clients want to update the same games at the same time - they are likely to corrupt the game data. So I would change the NFS or SMB share permissions so that access is Read Only. I'm not sure if this will break some games, but it shouldn't, most games should write to your home folders. It might cause Steam to complain. In which case the separate share per client with junctions for all the games might be a workaround - but still prohibiting write access to all but one on the common folder, because they will all download to separate directories then, and only run into problems when trying to update the common folder. (If you accidentally leave them on and they try to update). If they get into such a state, just stop steam, remove all files except the acf files and the common/game folder, and then restart steam, and it should continue. Unless it keeps state somewhere else too.