Error 0x80070040 — The Specified Network Name Is No Longer Available (Fix)

What This Error Means

You are in the middle of copying files to or from a mapped network drive. The transfer was working. Then:

An unexpected error is keeping you from copying the file. Error 0x80070040: The specified network name is no longer available.

Or in PowerShell or a script:

Copy-Item: The specified network name is no longer available. CategoryInfo: WriteError

The SMB session that was maintaining the connection to the network share was terminated mid-operation. The drive was mapped, the transfer was in progress, and then the connection dropped.

Root Cause 1 — The Host Machine Went to Sleep

The most common cause. If the host machine (the one with the shared folder) enters sleep mode while a transfer is in progress, the SMB session is terminated abruptly from the client's perspective.

Fix: On the host machine (the one hosting the share, not the one transferring):

Settings → System → Power & Sleep → Sleep → set to "Never" (when plugged in)

For a permanent fix on a machine intended to serve files, disable sleep entirely:

powercfg /change standby-timeout-ac 0
powercfg /change hibernate-timeout-ac 0

Root Cause 2 — Network Adapter Power Management Dropping the Link

Windows can turn off the network adapter to save power during periods of lower activity. This disrupts active SMB sessions and produces 0x80070040.

Fix on both the host and client machines:

1. Device Manager → Network Adapters → right-click your Ethernet adapter → Properties
2. Power Management tab → uncheck "Allow the computer to turn off this device to save power"
3. OK

Also check the Advanced tab:

• Find "Energy Efficient Ethernet" or "Green Ethernet" → if present, set to Disabled
• Find "Power Down Speed" → if present, set to Disabled

Root Cause 3 — SMB Session Timeout (Server-Side)

The SMB server has a session timeout — inactive sessions that have not exchanged data for a set period are disconnected. If a large file transfer has a long pause (e.g., waiting for the source disk), the session may time out during the pause.

Check and extend the timeout (on the host machine):

Get-SmbServerConfiguration | Select-Object AutoDisconnectTimeout

Default is 15 minutes (900 seconds). Set to 0 to disable auto-disconnect:

Set-SmbServerConfiguration -AutoDisconnectTimeout 0 -Force

Note: Disabling auto-disconnect keeps idle sessions alive indefinitely. On a machine with many users, this consumes more memory for session state. For a small office file server, it is an acceptable trade-off.

Root Cause 4 — WiFi Dropping or Roaming Mid-Transfer

If the transferring machine is on WiFi and is moving between access points (or experiencing brief signal loss), the network connection is momentarily interrupted, terminating the SMB session.

Fix: For any machine doing regular large file transfers: connect via wired Ethernet. A brief WiFi hiccup that a browser request recovers from invisibly will terminate an active SMB file copy.

For unavoidable WiFi situations: reduce roaming aggressiveness in the WiFi adapter settings (Device Manager → WiFi adapter → Advanced → Roaming Aggressiveness → set to Lowest) to prevent the adapter from dropping the current AP to search for a stronger one.

Root Cause 5 — Antivirus Scanning Interrupting the Transfer

Some antivirus products scan files as they are written to or read from network shares. If the scan takes too long and the SMB session stalls, 0x80070040 can occur.

Test: Temporarily disable real-time protection → retry the transfer → if it succeeds, add an exclusion for the network share path in your antivirus settings.

Root Cause 6 — The Host Machine Was Rebooted or Updated

Windows Update can schedule and apply updates with a machine restart during working hours, terminating all active SMB sessions. Mapped drives show the 0x80070040 error for transfers that were in progress at the time.

Fix: Configure Windows Update to install updates only during maintenance hours: Settings → Windows Update → Advanced options → Active hours → set to your office work hours.

Recovering After This Error

When 0x80070040 occurs mid-transfer:

1. Attempt to reconnect the mapped drive: open File Explorer → click the mapped drive (it may show a red X)
2. If it reconnects: confirm whether the partial transfer completed or failed — check the destination for a partial/incomplete file and the source to confirm the expected file size
3. Re-initiate any failed transfers

For large file transfers where partial failure is costly, consider using robocopy with the /r (retry) and /w (wait) flags — it automatically retries on network interruptions:

robocopy "Z:\LargeFiles" "D:\LocalCopy" /r:5 /w:10 /copyall /log:transfer.log

This retries failed files 5 times with a 10-second wait between retries, and logs the results.

---

Done losing transfers mid-way?

Oxolan transfers complete reliably over LAN — not over a fragile SMB session.

Get Oxolan for Windows

---

Frequently Asked Questions

The error appears only for very large files (over 10GB) but not small ones. Why? The SMB session timeout is the most likely cause — the large transfer takes long enough to approach the timeout threshold. Disable AutoDisconnectTimeout on the host (Root Cause 3 above).

We use a NAS and get this error. How is that different? NAS devices also have SMB session timeout settings. Check the NAS admin panel for an SMB idle timeout setting and extend it (in Synology DSM: Control Panel → File Services → SMB → Advanced Settings → Maximum protocol → check timeout settings).

After restarting the mapped drive, transfers fail immediately again. Why? The underlying issue is still present — the session is auto-disconnecting within seconds. Likely cause: network adapter power management turning off the link. Apply Root Cause 2 fix.

Can robocopy solve this entirely? Robocopy's retry logic handles transient disconnects well and is the recommended tool for scripted or critical large file transfers. For routine manual copies using File Explorer drag-and-drop, fixing the root cause (sleep, power management, timeout) is more appropriate.