Fix STATUS_OPLOCK_BREAK_IN_PROGRESS 0X00000108

Quick answer: Set your file transfer tool to retry 3–5 times with a 10-second delay between tries. Or just wait 30 seconds and redo the operation.

What’s actually happening here

When you see STATUS_OPLOCK_BREAK_IN_PROGRESS (0X00000108), you’re running into a file-locking handshake between Windows machines on a network. Oplocks (opportunistic locks) let one computer cache a file locally so it doesn’t have to ask the server for every read. That’s fast. But when another machine wants to open the same file for editing, Windows has to break the oplock — basically saying “hey, stop caching, the file is about to change.”

This error pops up when your operation (copy, move, open) tries to complete while that break is still happening. Think of it like trying to walk through a door that’s half-open and still moving. The operation times out or gets rejected because the lock hasn’t fully released yet.

I see this most often with:
— Automated backup scripts hitting shared folders on a file server.
— Bulk file moves with tools like xcopy or copy from the command line.
— Any program that opens files over SMB (Windows networking) super aggressively.

Step-by-step fixes

Start with the simplest fix — it works 80% of the time.

Fix 1: Just wait and retry

1. Close any program that might have the file open. That includes file explorers, text editors, and backup tools.
2. Wait a full 30 seconds. The oplock break usually completes in under 5 seconds, but give it a buffer.
3. Try your operation again. If it works, you’re done. The break completed in the background.

After waiting, you should see the file copy or move succeed without the error. If it doesn’t, move to Fix 2.

Fix 2: Use Robocopy with retry flags

The built-in robocopy tool handles this better than copy or Windows drag-and-drop. It can wait and retry when it hits an oplock break.

1. Open Command Prompt as Administrator. Right-click Start, pick “Command Prompt (Admin)” or “Terminal (Admin)”.
2. Run this command, replacing the source and destination paths with yours:

   robocopy "C:\SourceFolder" "\\Server\Share\DestFolder" *.* /R:5 /W:10

3. Press Enter. Watch the output.

Here’s what those flags do:
/R:5 — Retry up to 5 times if a file fails.
/W:10 — Wait 10 seconds between retries.

You should see Robocopy attempt the copy, hit the error, pause, then try again. After the retries, it either succeeds or moves to the next file. If it still fails after 5 retries, you’ve got a deeper lock issue (see Fix 3).

Fix 3: Disable oplocks on the file server (advanced)

This is a server-side change. Only do this if you own or control the file server. Disabling oplocks can slow down reads for some apps, so it’s a trade-off.

1. On the file server machine, open Registry Editor. Press Win + R, type regedit, hit Enter.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.
3. Look for a DWORD called EnableOplocks. If it’s not there, create it (right-click > New > DWORD (32-bit) Value).
4. Double-click EnableOplocks and set its value to 0.
5. Click OK, close Registry Editor, and restart the server or run this command in an admin Command Prompt:

   net stop server && net start server

After the restart, test the file operation again. The error should disappear. Remember — this is a nuclear option. Test it in a non-production environment first.

Alternative fixes if the main ones don’t work

If you can’t disable oplocks or Robocopy still fails, try these:

• Copy files one at a time. Use a simple loop in PowerShell: foreach ($file in Get-ChildItem "C:\Source") { Copy-Item $file.FullName "\\Server\Share\" -ErrorAction SilentlyContinue; Start-Sleep -Seconds 2 }. The delay gives each oplock break time to finish.
• Run the copy from the server side. Instead of pushing files from a client, log into the file server directly and pull files to the share. This removes the SMB negotiation that triggers the error.
• Check for antivirus scanning. Some antivirus software holds files open during scans. Temporarily disable real-time scanning on the server or exclude the shared folder to test.

Prevention tip

The best way to avoid this error long-term is to use a file transfer tool that handles retries automatically. Stop using drag-and-drop or basic xcopy for bulk network transfers. Stick with robocopy or a third-party tool like TeraCopy. Set retry count to 5 and wait time to 10 seconds. That handles 99% of oplock breaks without you ever noticing.

Also, if you’re running a busy file server, monitor oplock activity with Performance Monitor. Add the counter Server Work Queues\Oplock Breaks/sec. If you see sustained values above 10 per second, you might need to adjust your app’s file access patterns or upgrade network hardware.