Excel "Cannot access file.xlsx" Fix for Network Shares

You double-click a workbook sitting on a mapped drive, and Excel spits back: Cannot access 'Q:\Finance\Budget_2024.xlsx'. The file may be corrupted, located on a server that is not responding, or read-only. The file opens fine on your coworker's PC. It opens fine from your desktop if you copy it locally. It just won't open over the network. Sometimes it opens, you edit for ten minutes, hit Save, and then everything locks up with the same error.

The three causes listed in the message — corruption, dead server, read-only — are almost never the real problem. What's actually happening is that the SMB session between your machine and the file server has gone stale, or a lock file is hanging around pretending someone's still editing. Excel is just reporting what Windows told it, and Windows is confused.

Why this error shows up (the short version)

When you open an xlsx over a network share, Excel does three things in quick succession: it checks for a lock file (a hidden ~$Budget_2024.xlsx next to the real file), it opens a handle, then it holds that handle for the whole session. If any of those steps fails, you get this error.

Common triggers I see in tickets:

You put the laptop to sleep while the workbook was open. On wake, Windows reconnects to Wi-Fi but the SMB session to the file server is dead. Excel still thinks the file is open.
You VPN'd in yesterday, closed the laptop, came back today. The mapped drive shows in Explorer but the underlying TCP session to the server is gone.
Excel crashed or you killed it from Task Manager. The lock file ~$file.xlsx never got cleaned up.
Someone on the team opened the file read-only, then their machine went offline. Now the lock file persists and everyone else gets "read-only" or access errors.
Credentials cached in Windows Credential Manager are for a domain account that's since been disabled or had its password changed.

The reason step 3 below works is that it forces Windows to tear down the stale session and renegotiate authentication from scratch. Restarting Excel alone doesn't do that — Excel isn't the component holding the dead connection, mrxsmb and the Workstation service are.

The fix, in order

Close Excel completely and kill orphan processes. Not just the window — the process. Open Task Manager, look for EXCEL.EXE under Details, and end every instance. If you see ~$YourFile.xlsx next to the real file in Explorer, that's the lock file. Delete it — but only after confirming no one else has the file open. On a share, right-click and check Properties; if it's owned by a user who's been offline for days, it's safe to remove.
Reconnect the mapped drive properly. Don't just click it in Explorer — that can trigger a lazy reconnect that half-works. Open an elevated Command Prompt and run:
```
net use Q: /delete /y
net use Q: \\fileserver\share /persistent:yes
```
If you get "System error 1219 has occurred" (multiple connections to a server by the same user are not allowed), that's your real error hiding behind Excel's message. Log off and back on, or map the share using its FQDN instead of the NetBIOS name.
Clear stale credentials. Hit Win+R, run control /name Microsoft.CredentialManager, and look under Windows Credentials for anything pointing at your file server. Remove those entries. Next time you connect you'll be re-prompted with a valid token. This is the fix for the case where the file opens on Tuesday but not Wednesday after a password reset.
Kill the Workstation service and restart it. This is the nuclear option that clears every cached SMB session on the machine. Run as admin:
```
net stop workstation /y
net start workstation
```
It takes about eight seconds. Any open Explorer windows pointing at network shares will need a refresh. Your local drives are unaffected. If you're on a laptop that just came out of sleep, this alone fixes the error about 80% of the time.
Check Protected View and untrusted locations. If the file lives on a \\server path that Excel treats as "Internet" (this happens with DFS namespaces and some VPN adapters), it drops into Protected View. Protected View can't write the lock file, and you get the same error message. Go to File → Options → Trust Center → Trust Center Settings → Protected View and uncheck "Enable Protected View for files located in potentially unsafe locations" — or better, add the share to Trusted Locations under Trust Center → Trusted Locations. Use the UNC path, not the mapped letter.
Bypass the network entirely to isolate the problem. Copy the file to C:\Temp\ and open it. If it opens locally, the file is fine and the problem is 100% transport. If it fails locally too, then it really is corrupt — open it with File → Open → Open and Repair, or use excel.exe /safe to rule out add-ins.

If it still fails

Check these, in order:

Is the server actually responding? Ping it, then try \\fileserver\share in Explorer directly. If Explorer hangs, the issue isn't Excel.
DFS namespace? DFS referrals go stale on VPNs. Open the share via the underlying server name (\\server01\share instead of \\domain\share) and see if it opens. If yes, your DFS cache needs flushing: dfsutil /pktflush.
Offline Files (CSC) turned on? If Offline Files is enabled on that share, Windows may serve you a cached copy that's out of sync. Check Sync Center and either sync manually or disable offline caching on the share.
Antivirus scanning the share? Real-time scanners hold file handles for a few hundred milliseconds after open — long enough to break Excel's lock check on slow links. Add the share to your AV exclusion list.
Wrong SMB version negotiated? If the server is old (Server 2008 R2 or a NAS), it may still be trying SMB1. Microsoft disabled SMB1 by default in Windows 10 1709 and later. If your NAS only speaks SMB1, you'll get intermittent failures exactly like this. The fix is to enable SMB2/3 on the NAS, not to re-enable SMB1 on your PC.
File path length. Any path over 259 characters fails silently on some older Excel builds. Move the file closer to the drive root and try again.

If nothing above works and the file opens fine from a different machine on the same network, the problem is local to your Windows profile. Create a fresh user profile and test there before you spend another hour on it — profile corruption breaks SMB in ways that look exactly like file corruption.