ERROR_WAIT_FOR_OPLOCK 0X000002FD fix: blocked SMB file ops

Cause 1: Third-party antivirus or backup software holding oplocks

What's actually happening here is your file system is waiting on an opportunistic lock (oplock) that another process — typically antivirus, backup, or cloud sync software — hasn't released. Windows uses oplocks to let one client cache file data locally and avoid unnecessary network traffic. But when the lock holder doesn't respond fast enough, you get 0x000002FD. I've seen this most often with McAfee Endpoint Security, Carbonite Backup, and OneDrive Files On-Demand on Windows 10 22H2 and Windows 11 23H2.

Fix: Temporarily disable or reconfigure the offending software

1. Open Task Manager (Ctrl+Shift+Esc) and go to the Startup tab.
2. Look for anything from your AV or backup vendor. Right-click and disable it.
3. Reboot. If the error disappears, you've found the culprit.

If you can't disable the software (corporate policy, I get it), you can often add an exception for the specific file path or network share. For example, in Windows Defender (Microsoft Defender Antivirus), open Windows Security > Virus & threat protection > Manage settings > Exclusions, then add the folder path that triggers 0x000002FD.

The reason step 3 works is that Defender will stop intercepting every file open call on that share, which in turn stops breaking the oplock lease chain. If you're not sure which software is the issue, check Event Viewer: look for Event ID 5705 under Applications and Services Logs/Microsoft/Windows/SmbClient/Operational. That log entry includes the process ID that owns the offending oplock.

Cause 2: Stale SMB handles from network disconnects

Another common trigger: you disconnect from a mapped network drive (or VPN drops) while a file is still open. Windows keeps the oplock handle alive for a while, and when you reconnect, the new operation collides with the dead handle. This is especially nasty on Windows 11 22H2 with SMB over QUIC — the oplock timeout is longer by default.

Fix: Clear stale SMB connections and reduce oplock timeout

First, kill the dead handles:

net use * /delete /y

Then check if any handles remain with:

net session | find /i "client"

If you still see entries, reboot clean. But prevention is better: reduce the oplock timeout via registry so stale handles expire faster.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"OplockTimeout"=dword:00001f40

That sets the timeout to 8000 milliseconds (8 seconds) instead of the default 60 seconds on most builds. You'll need to reboot after applying. Don't go lower than 5 seconds — I've seen some apps (looking at you, Adobe Creative Cloud) break if the oplock drops too fast.

The reason this works: by shrinking the window where a stale oplock can block new requests, you turn a 60-second application hang into an 8-second bump that most software can retry through.

Cause 3: Misconfigured SMB server oplock policies on the remote machine

Less common but more infuriating: the file server (Windows Server, NAS, or even a Linux Samba share) has custom oplock settings that clash with your client. I hit this once on a Synology NAS running DSM 7.2 with SMB3 — the admin had enabled “oplocks disabled” in the share settings for one folder, but not others. The mixed state confused Windows clients.

Fix: Check server-side oplock settings

If you control the server, verify these registry values (on Windows Server):

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
"EnableOplocks"=dword:00000001
"EnableOplockForceClose"=dword:00000001

For Samba servers (Linux/NAS), check /etc/samba/smb.conf:

[global]
oplocks = yes
level2 oplocks = yes
kernel oplocks = no

On a Synology NAS, that's under Control Panel > File Services > SMB > Advanced Settings — make sure Enable SMB2/3 durable handles is checked, but Disable opportunistic locking is not checked.

If you can't access the server, test by mounting the share on a different client (different OS version, different AV). If the second client works fine, the problem is client-side — go back to Cause 1 or 2. If both fail, it's the server.

Quick-reference summary

If none of these resolve it, you're likely dealing with a hardware issue — particularly on USB-to-SATA adapters or older NICs that drop packets. Run fsutil behavior query oplocks — if it returns 2 (always disable oplocks), set it back to 1 with fsutil behavior set oplocks 1 and reboot. Some sysadmin guides tell you to disable oplocks globally to fix errors like this, but that kills performance on network file access. Don't do it.