Fix STATUS_FILE_CHECKED_OUT (0xC0000901) on Windows

Cause 1: Another user has the file checked out (SharePoint, OneDrive, Teams)

If you're hitting 0xC0000901 on a file that lives in SharePoint, OneDrive for Business, or a Teams document library, the culprit is almost always a check-out flag baked into the file's metadata. Word, Excel, and PowerPoint default to requiring check-out on some corporate libraries. The moment Judy in accounting opened that Q3 budget sheet and clicked "Check Out," the file got tagged as locked — even if she closed the app an hour ago without checking back in.

The error shows up in File Explorer as a generic "This file is checked out or locked for editing by another user" dialog, and in developer tools it surfaces as the raw NTSTATUS 0xC0000901. Same underlying thing.

The fix

1. Open the file's parent library in the browser (sharepoint.com/sites/... or onedrive.live.com).
2. Find the file, click the three-dot menu, and look for Check in, Discard check out, or Version history.
3. If you're an owner or site admin, you can force-discard someone else's check-out from the file's Manage access panel. Do it — Judy won't notice.
4. In Office apps, the check-out state sometimes survives a sync. Right-click the file in Explorer and pick Free up space, then let OneDrive re-download it. That clears the stale lock flag.

Skip the urge to delete and re-upload the file. You'll wipe the version history and your SharePoint admin will have words with you.

Cause 2: A local process still has an open handle

No SharePoint involved? Then it's a local Windows lock. Something on the machine grabbed an exclusive handle on the file and never let go. Classic offenders:

• Excel or Word crashed but the process didn't actually die (look for EXCEL.EXE in Task Manager with 0% CPU and no window).
• Antivirus scanning a file mid-write and holding the handle.
• Backup software (Veeam, Acronis) doing a VSS snapshot.
• A rogue script or Python process that opened the file with O_EXCL.

The fix

Start with Task Manager. Kill every Office process, every WINWORD.EXE, every EXCEL.EXE, even the ones you think aren't running. Half the time that's it.

If it's still locked, find the actual handle holder with Sysinternals Handle. Download it once, run it as admin:

handle.exe -a "C:\path\to\your\file.xlsx"

You'll get a PID. Cross-reference it in Task Manager or with tasklist /FI "PID eq 1234". Kill the process — carefully. If it's a system process, don't touch it; reboot instead.

On a file server, the same trick works through OpenFiles or the newer PowerShell cmdlet:

Get-SmbOpenFile | Where-Object { $_.Path -like "*file.xlsx*" } | Close-SmbOpenFile -Force

Don't bother with "unlocker" utilities from random download sites. Half of them are adware and the other half just reboot the machine under the hood.

Cause 3: Stale NTFS lock or permissions mess on an SMB share

On a mapped drive or UNC path (\\server\share\file.docx), 0xC0000901 can come from a leftover opportunistic lock (oplock) that didn't get released when the client's session dropped. This happens a lot on Wi-Fi. Laptop suspends mid-save, network drops, the file server still thinks the client has the file checked out. Reconnecting doesn't fix it because the lease is cached server-side.

Permissions also throw the same code when an inherited ACL is broken or the file is owned by a deleted SID. If you've migrated between domains or restored from an old backup, this is a real possibility.

The fix

1. On the server, open an elevated PowerShell and list open handles for the share:

   Get-SmbOpenFile | Format-Table ClientUserName, ClientComputerName, Path

2. Find entries with a stale client computer name — old laptop, decommissioned VM. Close them:

   Close-SmbOpenFile -FileId <id> -Force

3. If the file still refuses to open, check the ACL:

   icacls "\\server\share\file.docx"

   Look for SIDs that show up as S-1-5-21-... instead of a name. That's a ghost from a dead domain. Reset ownership as an admin: takeown /f file.docx, then icacls file.docx /reset.
4. Last resort: restart the Server service on the file server. Not the whole box — just the service. It clears every cached handle and takes 5 seconds.

When it comes to SMB, disabling SMB2 leasing via registry is a bad idea. It hurts performance across the board and it's a hack, not a fix. Restart the service instead.

Quick reference

A reboot clears the local case 95% of the time, so if you just need to ship the file today, do that. But if this keeps happening on the same share, it's a stale oplock or bad ACL, and rebooting every morning isn't a fix — it's a symptom.