Fix STATUS_OPLOCK_NOT_GRANTED (0XC00000E2) on Windows
This error means Windows denied an opportunistic lock request. It usually happens during file transfers or database operations over a network. The fix is often adjusting SMB settings or disabling oplocks.
I know this error is infuriating—especially when it kills a file copy mid-transfer or crashes your database app. Let me save you the headache I went through the first time.
The Quick Fix: Disable Oplocks on the Server
On the machine hosting the shared files (the server), open Registry Editor as Administrator. Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersCreate a new DWORD (32-bit) called EnableOplocks and set it to 0. Restart the server service or reboot. That's it. This disables opportunistic locks entirely for SMB shares. No more 0XC00000E2 for most people.
If you're on Windows Server 2012 R2 or newer, you can also run this in an admin PowerShell session:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' -Name 'EnableOplocks' -Value 0 -Type DWord
Restart-Service -Name LanmanServer -ForceWhy This Works
An opportunistic lock (oplock) lets a client cache file data locally to reduce network chatter. The problem? When another client requests the same file, Windows denies the oplock to avoid corruption. If your app doesn't handle the denial gracefully, you get 0XC00000E2. Disabling oplocks forces every read and write to go through the server—slower but stable.
I've seen this error most often with:
- SQL Server databases on network shares (e.g., a shared .mdf file)
- Large file copies over SMB (especially with antivirus scanning them)
- Legacy apps that don't retry after an oplock denial
Less Common Variations
If the above doesn't work, or you can't change server settings, try these:
1. Disable Oplocks per Share (Windows Server)
Instead of global disable, you can do it for specific shares. In Registry, go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\SharesFind your share name as a REG_MULTI_SZ key. Add the line EnableOplocks=0 to its value data. Restart the server service.
2. Disable SMB2/3 Oplocks (Client Side)
If you're on Windows 10/11 and connecting to a NAS or server you don't control, you can disable oplocks on the client. This is risky—it can hurt performance—but it works. Open an admin PowerShell:
Set-SmbClientConfiguration -EnableOplocks $false -ForceReboot. To revert: Set-SmbClientConfiguration -EnableOplocks $true -Force.
3. Increase Oplock Break Notification Timeout
For SQL Server specifically, increase the oplock break wait time. In registry under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, add DWORD OplockBreakWait and set it to a value like 60 (seconds). Default is 35.
Note: If you use Hyper-V or SQL Server on the same machine hosting file shares, disabling oplocks globally can cause performance regressions. Test in a non-production environment first.
Prevention
To avoid this error in the future:
- Move databases and VM files off network shares—use local storage or iSCSI instead.
- Keep antivirus real-time scanning off SMB shares unless absolutely needed.
- Update all SMB clients to Windows 10 1809+ or Server 2019+, which handle oplock denials better.
- If you must keep oplocks enabled, ensure all apps that touch those files can retry on denial. SQL Server does this natively; most backup tools don't.
Give the registry fix a shot. It's saved my bacon more times than I can count. If you're still stuck, check the Windows System event log for Event ID 50 or Event ID 55—they'll tell you exactly which file triggered the denial.
Was this solution helpful?