Quick answer
Disable write caching on the network drive's properties (Device Manager > Disk Drives > Properties > Policies > 'Quick removal') and increase SMB idle timeout on the server via net config server /autodisconnect:-1.
What's actually happening here
Windows uses a write-behind cache for network drives — it tells your app the file is saved before the data actually hits the server's disk. This speeds things up normally, but when the network connection drops or the server disconnects the session (default SMB idle timeout is 15 minutes), Windows can't flush that cache. The result: error 0x315, often accompanied by a notification that 'data was lost for the file' on your mapped drive. I see this most often with mapped drives to NAS boxes or older Windows Server 2008/2012 boxes where TCP keepalives aren't configured. You're usually opening or saving a file from a network share, the app hangs for 10–20 seconds, then the error pops.
Fix steps
- Disable write caching on the client
Open Device Manager, expand 'Disk drives', right-click the network drive (it shows as a local disk but has a network path), go Properties > Policies. Select 'Quick removal' (disables write caching). This forces all writes to be synchronous, so every save waits for server confirmation. Slower but reliable. You'll lose a bit of write speed, but the error disappears. - Increase SMB idle timeout on the server
On the server hosting the share, open Command Prompt as admin and run:
This disables the auto-disconnect feature that drops idle sessions after 15 minutes. If you can't access the server, ask the admin or use group policy: Computer Configuration > Administrative Templates > Network > Lanman Workstation > 'Disconnect idle sessions' — set to 'Never'.net config server /autodisconnect:-1 - Set TCP keepalive on client
Open regedit, go toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Create or setKeepAliveTime(DWORD) to30000(30 seconds) andKeepAliveInterval(DWORD) to1000(1 second). This forces Windows to detect dead connections faster rather than waiting for the default 2 hours. Reboot. - Enable SMB signing or disable it
If the server requires SMB signing and the client has it disabled (or vice versa), negotiation failures cause silent disconnects. On client: rungpedit.msc> Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Microsoft network client: Digitally sign communications (always)' — set to Enabled. Or if you don't need signing, set it to Disabled on both sides.
Alternative fixes
If the above doesn't help (rare, but possible with flaky Wi-Fi), try these:
- Remap the drive with persistent flag
Delete the mapped drive and remap usingnet use Z: \\server\share /persistent:yes. The/persistent:yesflag makes Windows re-establish the connection automatically on reconnection, reducing orphaned sessions. - Increase IRPStackSize
Registry key atHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\IRPStackSize— set to20(decimal). This gives more buffer for I/O request packets on busy networks. Default is 15. Reboot. - Use IP address instead of hostname
Sometimes DNS or NetBIOS resolution causes delays that trigger the disconnect. Map the drive using\\192.168.1.100\shareinstead of the server name.
Prevention tip
The root cause is almost always a dropped session. Configure your NAS or Windows server to never disconnect idle sessions, and on the client, reduce TCP keepalive to 30 seconds. If you're on a Wi-Fi network, set the adapter's power management to 'Maximum Performance' — even a brief power-saving pause can drop the SMB connection. For critical files, use a local copy first, then sync with robocopy. Write-behind caching is fine for local disks, but on a network, it's a gamble you don't need to take.