Fix 'The Semaphore Timeout Period Has Expired' Error on Windows Network Share

The Error

You try to access a network share, map a drive, or copy files over the network — and Windows stops you cold:

System error 121 has occurred.
The semaphore timeout period has expired. (0x80070079)

Sometimes it shows up as a generic "Network path not found" dialog. In PowerShell you'll see the hex code 0x80070079 instead. Either way, same root cause: Windows sent an SMB request, waited about 45 seconds, and gave up.

What's Actually Happening

Error 121 is Windows hitting a hard deadline at the network layer. The OS fired off a request to the remote host, the remote host never answered in time, and Windows declared the connection dead. Four things cause this almost every time: a flaky NIC driver, an SMB packet signing mismatch, an overloaded file server, or a firewall silently dropping packets mid-handshake. The tricky part is they all look identical from the outside.

Step-by-Step Fix

Step 1 — Check Basic Connectivity First

Don't touch any settings yet. First confirm the host is reachable and port 445 is actually open:

# Ping with extended count to catch intermittent drops
ping -n 20 192.168.1.100

# Check if SMB port is open
Test-NetConnection -ComputerName 192.168.1.100 -Port 445

If TcpTestSucceeded returns False, you have a network-level problem — jump straight to Step 4. If ping shows packet loss (even 1–2 out of 20), your cable or Wi-Fi is the likely culprit, not SMB.

Step 2 — Disable SMB Packet Signing (Mismatch Fix)

A signing mismatch between client and server is one of the sneakier causes. When the server requires signing but the client doesn't negotiate it correctly, connections time out rather than giving you a clean auth error. Check your current client state:

Get-SmbClientConfiguration | Select RequireSecuritySignature, EnableSecuritySignature

Temporarily disable required signing on the client to isolate the issue:

# Run PowerShell as Administrator
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

If that stops the error, align the signing policy on both machines. Don't just leave signing disabled — it's a meaningful security control on internal networks.

Step 3 — Disable Large Send Offload (LSO)

LSO lets the NIC handle TCP segmentation instead of the CPU. Sounds great in theory. In practice, certain Intel and Realtek drivers — especially versions shipped between 2020–2023 — silently drop large SMB packets when LSO is active, and the only symptom is random timeouts.

Open Device Manager (devmgmt.msc), expand Network Adapters, right-click your adapter → Properties → Advanced tab. Disable these entries if they exist:

• Large Send Offload v2 (IPv4)
• Large Send Offload v2 (IPv6)
• TCP Checksum Offload (IPv4)

Rather use PowerShell:

# List your adapter name
Get-NetAdapter

# Disable LSO (replace "Ethernet" with your adapter name)
Disable-NetAdapterLso -Name "Ethernet"

# Disable TCP checksum offload
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "TCP Checksum Offload (IPv4)" -DisplayValue "Disabled"

Restart the adapter to apply:

Restart-NetAdapter -Name "Ethernet"

This fix resolves error 121 in roughly half of cases involving physical machines on a LAN.

Step 4 — Check Windows Firewall and SMB Ports

Run these on the server side, not the client:

# Enable File and Printer Sharing rules
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

# Confirm port 445 is actually listening
netstat -an | findstr ":445"

If you're going through a managed switch or router, check whether ports 445 (SMB) and 139 (NetBIOS) are being rate-limited or quietly blocked. Some consumer routers throttle SMB traffic by default under "application control" settings.

Step 5 — Flush DNS and Reset Network Stack

Stale DNS cache or a corrupted TCP/IP stack can push connection setup times past the timeout threshold. Run this sequence:

# Flush DNS cache
ipconfig /flushdns

# Reset TCP/IP stack
netsh int ip reset
netsh winsock reset

# Release and renew DHCP lease
ipconfig /release
ipconfig /renew

Reboot after. The netsh int ip reset command rewrites the TCP/IP registry keys — a reboot is required for them to take effect.

Step 6 — Update or Roll Back NIC Driver

Still broken? The driver is now the prime suspect. Check what you're running:

Get-NetAdapter | Select Name, DriverVersion, DriverDate

Get the latest driver directly from the manufacturer's site — Intel, Realtek, or Broadcom — not Windows Update. Windows Update often ships drivers 6–12 months behind the vendor's current release. If the error started right after a driver update, roll back: Device Manager → right-click adapter → Properties → Driver tab → Roll Back Driver.

Verify the Fix

Map the drive and hit it with a real workload — a directory listing isn't enough to confirm stability:

# Map the drive and list contents
net use Z: \\192.168.1.100\sharename /persistent:yes
dir Z:\

# Copy a test file and verify integrity
copy Z:\testfile.bin C:\Temp\testfile.bin
certutil -hashfile C:\Temp\testfile.bin SHA256

A clean dir with no timeout and a matching SHA-256 hash confirms the fix held. For quick checksum comparisons, ToolCraft's Hash Generator runs entirely in-browser — paste both hashes and it tells you instantly whether source and destination match.

Tips

• Wi-Fi users: Switch to a wired connection for sustained SMB transfers. Wi-Fi latency spikes — especially on congested 2.4 GHz channels — regularly push past error 121's threshold under load. A cheap Cat6 cable eliminates the variable entirely.
• VPN + SMB: MTU mismatch is the classic culprit here. The VPN tunnel fragments SMB packets, the server never gets a complete frame, timeout. Set the MTU on your VPN adapter to 1400: netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent
• Wrong subnet: If the share is across subnets, use ToolCraft's Subnet Calculator to confirm the routing is correct and the client is actually hitting the right host.
• Event logs: Open eventvwr.msc → Windows Logs → System and filter for Srv or MRxSmb source events around the time of failure. These entries usually say outright whether the timeout originated client-side or server-side.
• Old servers (pre-2012): They may only support SMB1. Verify with Get-SmbServerConfiguration | Select EnableSMB1Protocol. Enabling SMB1 is a real security risk — it's exploitable via EternalBlue — so treat it as a last resort and plan an upgrade.