Skip to content
English - Australia
Contact us
  • There are no suggestions because the search field is empty.

Windows File Share Unavailable — Server Service Recovery & Root Cause Checklist

Users lose access to a network file share hosted on a specific server. The share becomes unreachable (\\servername\share) even though the server otherwise appears online.

Immediate Fix

On the server hosting the share (not on the affected client machines), restart the Server service, which handles SMB file sharing:

powershell 
Restart-Service LanmanServer -Force

The -Force flag is required because the Server service has dependent services attached — a plain restart often fails with a dependency error without it.

Before restarting, optionally check who is connected:

powershell 
Get-SmbSession Get-SmbOpenFile

Warning: Restarting this service immediately drops all active SMB sessions and open file handles. Anyone connected at that moment will be disconnected, and unsaved work in open files may be lost.

GUI alternative: services.msc → find Server → right-click → Restart.

Once restarted, shares should reappear for users within a few seconds.

If This Recurs on the Same Server

A single incident is a nuisance; a repeat pattern on the same server means something is causing the service to crash, hang, or stop — worth diagnosing rather than just restarting each time.

Check the System event log around the time of the outage:

powershell 
Get-WinEvent -LogName System | Where-Object {$_.Message -like "*Server*" -or $_.ProviderName -like "*srv*"} | Select-Object -First 50 TimeCreated, Id, ProviderName, Message

Look specifically for:

  • Service Control Manager events (7031/7034) — service crashed and either restarted or didn't
  • Srv/SrvNet/Srv2 provider errors — the SMB driver itself failing
  • Event ID 2013 (srv) — non-paged pool memory running low, a common cause of SMB becoming unresponsive
  • Any event logged just before the outage that could be the trigger

Common root causes to rule out:

  • NIC driver/offload issues (RSS, RSC, Large Send Offload) — a frequent cause of SMB failing on one box while the rest of the server looks fine
  • Non-paged pool exhaustion — check with Get-Counter '\Memory\Pool Nonpaged Bytes' over time for a leak
  • AV/EDR software interfering with SMB traffic, especially after an agent or signature update
  • Backup jobs locking open files aggressively enough to take SMB down
  • Incomplete patch cycles or a scheduled task bouncing the network stack
  • If virtualized: host/storage latency causing the same symptom

Escalation: If the fix needs to be repeated more than once, log it as a recurring incident and escalate for root-cause investigation rather than continuing to apply the workaround.