Office Save Errors 0x80070070 and 0x8007003B on Network Shares and Mapped Drives

Fix it now

Your document is still in memory while you read this, so save it somewhere safe before you troubleshoot anything. The save failed underneath Office: 0x80070070 is a full disk, 0x8007003B is an unexpected network error, and 0x80070040 is the share no longer being there at all.

1. Do not close the application. Use File > Save As and write the document to a local folder such as C:\Temp, so the work survives whatever happens next.
2. If Save As also fails, save the sheets or the content into a brand new document and save that instead. Microsoft lists this as the next recovery step precisely because it sidesteps whatever the original file is stuck on.
3. Check free space on the target volume, and check your own quota separately. A share with gigabytes free reports an identical error when your quota is spent.
4. Rebuild the connection: run net use to see the mappings, remove the failed one and map it again, then reopen the document from the new mapping rather than the old path.
5. Count the path. Microsoft names a 218-character limit on the full path for a saved workbook, and a deep folder tree on a long UNC reaches it more easily than people expect.
6. Save the local copy back over the network file once the share is healthy, and check the folder for temporary files the failed attempts left behind.

Never respond to a save failure by closing the document to try again. Once the application closes, unsaved content is gone and no amount of share repair brings it back.

If the document is saved locally you have already protected the work. The next section explains how Office writes a file and which of the three codes you are looking at.

Why it happens

Office does not overwrite your document in place. Microsoft describes the mechanism plainly for Excel: while you work, the file is saved automatically under a temporary name in the same folder as the original, and when you save manually the original is deleted and the temporary file takes its name. That is what stops a failed save destroying the previous version. It also means a save needs free space for a second copy of the file, and rights to create and delete in the folder rather than merely to modify the file already there.

Over SMB every one of those steps travels across a session that has to survive from beginning to end. Sessions get torn down by idle timeouts, by a laptop moving between access points, by a network adapter being powered down to save energy, and by failover events. Break the session between the write and the rename and you get a network error, often with a temporary file left behind under a scrambled name.

The three codes divide the problem cleanly. 0x80070070 is Windows error 112, ERROR_DISK_FULL, “There is not enough space on the disk” – and a quota that is spent reports the same way as a volume that is full. 0x8007003B is error 59, ERROR_UNEXP_NET_ERR, “An unexpected network error occurred”, which is what a dropped session looks like from the client. 0x80070040 is error 64, ERROR_NETNAME_DELETED, “The specified network name is no longer available”, meaning the share or the mapping has gone rather than merely become slow.

Full reference

Microsoft’s own recovery order, most formatting preserved first

1. Save under a new file name with File > Save As.
2. Move the worksheets into a new workbook: add a filler sheet with Shift+F11, group the sheets, then right-click and use Move or copy into a new book.
3. Save in a different Excel format – .xlsx or .xlsm rather than .xls.
4. Save to another location: a local disk, a different network drive, or removable media.
5. Test whether a brand new, empty workbook will save to the original location at all.
6. Restart Windows in safe mode and try the save from there.

That order matters when you are standing over someone’s shoulder with unsaved work on screen. Each step costs a little more of the document’s formatting than the one before, so working down the list means you give up as little as possible.

Causes Microsoft names for a failed save

• Third-party add-ins, and files sitting in the application’s startup locations.
• Restricted permissions on network drives.
• Insufficient space on the destination.
• A lost connection to the workbook.
• Conflicts with antivirus software.
• Problems with shared workbooks.
• A full path longer than 218 characters.

Commands worth having open

Leftover temporary files

A folder that has been failing saves for weeks fills with temporary files under scrambled names. They are the second half of interrupted saves and they are safe to remove once nobody has the documents open, but do not remove them while a save is in progress. Their presence is a useful signal in itself: a folder with dozens of them has been dropping sessions for a long time, whatever the person reporting it thinks started yesterday.

Working locally and copying up at the end is a reasonable stopgap during an incident and a poor policy afterwards. Local copies do not get backed up, versions diverge, and the share problem stays unfixed because nobody is hitting it any more.

Every code this article covers

Confirm the fix worked

1. Save a small test document into the same folder and confirm it completes without a message.
2. Reopen the file from the share and check the content matches what was last on screen.
3. Confirm no leftover temporary files remain in the folder from the failed attempts.
4. Leave a document open for an hour, then save, to prove the session survives an idle period.
5. Repeat the test from a second machine on the same subnet, to separate a client fault from a share fault.

Questions people ask about this