Windows · Windows Server  ·  medium  ·  Microsoft Office

"File is locked for editing by another user" — including when that user is you

A document opens read-only and names someone who is not in it — sometimes the person trying to open it. A stale owner file, an open handle on the file server, or a SharePoint checkout is holding the lock after the session that created it has gone.

What you see

"File in use — document is locked for editing by another user" naming a colleague who has it closed, or naming the current user, or showing "another user". Read-only opens fine; taking the lock never becomes available.

What is actually wrong

Office creates a hidden owner file named ~$ plus the document name and deletes it on a clean close. A crash, a dropped VPN or a killed process leaves it behind and the lock outlives the session. On a file server the SMB handle can outlive the client for the same reason. In SharePoint and OneDrive the equivalent is a checkout, or a lock the service holds for up to ten minutes after a client disappears.

Codes and articles

locked for editingfile in use~$ owner filechecked outread-only office

Start here — find out which fix applies

A script that runs the 2 inspection commands from the write-up below and prints what each one returned. It reads the machine and changes nothing — every command that could write, delete, start or stop is excluded from it by construction. Run this first, then pick the fix its output points at.

Download the read-only diagnosticchanges nothing · safe to run before reading

Fixes (3)

Remove the stale owner file
PowerShell as a user with write access to the folder10 minuteslow riskreversible

Always check this first, wherever the file lives. It costs a minute and it is the answer most of the time.

  1. Confirm nobody genuinely has the document open. Ask, do not assume — deleting the owner file while someone is editing invites two people saving over each other.

  2. Find the owner file. It is hidden, so it will not show in Explorer with default settings.

    PowerShell
    Get-ChildItem '\\fileserver\share\folder' -Filter '~$*' -Force | Select-Object Name, LastWriteTime, Length

    The LastWriteTime tells you when the session that left it behind started. One from three weeks ago is certainly stale; one from four minutes ago probably means someone really is in the file.

  3. Delete the owner file for the document in question. The name is ~$ followed by the document name, sometimes with the first characters truncated.

    PowerShell
    Remove-Item '\\fileserver\share\folder\~$Budget.xlsx' -Force

  4. Reopen the document. It should now open for editing.

Confirm it workedThe document opens with write access and the title bar does not say Read-Only.
If you need to undo itNothing to restore — Office recreates the owner file on the next open. The file itself is never touched by this.
Download this fix as a PowerShell script2 steps you do yourself · asks before each step
Close the stale handle on the file server
PowerShell as administrator on the file server20 minutesmedium risknot reversible

The owner file is gone or absent and the lock persists, and the file is on a Windows file server. Closing a handle that is genuinely in use discards any unsaved work in that session without warning the person doing the work, so confirm the session is stale before you close anything.

  1. Find the open handle by file name.

    PowerShell
    Get-SmbOpenFile | Where-Object Path -like '*Budget.xlsx*' | Select-Object FileId, SessionId, ClientUserName, ClientComputerName, Path

  2. Check whether that session is actually alive before closing anything.

    PowerShell
    Get-SmbSession -SessionId <SessionId> | Select-Object ClientComputerName, ClientUserName, NumOpens, SecondsIdle

    A high SecondsIdle on a session whose owner says they are not in the file is the confirmation you want. Closing a live handle discards whatever that client has not yet written.

  3. Close the handle.

    PowerShell
    Close-SmbOpenFile -FileId <FileId> -Force

  4. Have the user reopen the document.

  5. If this happens repeatedly on the same share, look at the underlying cause rather than closing handles forever — an unstable VPN, roaming laptops sleeping with files open, or oplocks misbehaving with a third-party filter driver are the usual three.

Confirm it workedThe handle no longer appears and the document opens for editing.
PowerShell
Get-SmbOpenFile | Where-Object Path -like '*Budget.xlsx*'
If you need to undo itA closed handle cannot be reopened server-side — the client simply reconnects.
Download this fix as a PowerShell scriptnot reversible · needs an elevated shell · 2 steps you do yourself · asks before each step
Release a SharePoint or OneDrive lock
The browser, as the document owner or a site administrator30 minuteslow riskreversible

The file is in SharePoint, Teams or OneDrive.

  1. Open the library in the browser and check whether the file shows as checked out. A checked-out file shows a small green arrow, and its Checked Out To column names the holder.

  2. If it is checked out, discard the checkout from the library — the ⋯ menu → More → Discard check out. A site administrator can do this for anyone else's checkout.

  3. If it is not checked out, wait ten minutes. A short-term lock is taken when a client opens the file and is released automatically when the client disappears; there is no way to clear it early and no reason to.

    This is the step people skip, and it is why the same file is reported three times in twenty minutes. The lock expires on its own.

  4. Have the user close Office completely and let the sync client settle, since a local Office process holding the file will keep re-taking the lock.

    PowerShell
    Get-Process WINWORD,EXCEL,POWERPNT -ErrorAction SilentlyContinue | Stop-Process -Force

  5. If the document keeps locking for one user only, check they are opening it from the sync client or the browser and not through a mapped drive to the SharePoint URL, which does not participate in co-authoring properly.

Confirm it workedThe file opens for editing in the browser and in the desktop application, and version history shows the new save.
If you need to undo itDiscarding a checkout loses changes that were never checked in — check version history first if that is a concern.
Download this fix as a PowerShell scriptneeds an elevated shell · 4 steps you do yourself · asks before each step

Related faults

A document always opens read-onlyWindowsOffice applications open slowly, hang, or start with a blank windowWindows"Microsoft has blocked macros from running because the source of this file is untrusted"WindowsA document will not open — Protected View, "file format is not valid", or a corrupt fileWindowsDouble-clicking a file opens Office but not the documentWindowsAutoSave is greyed out, or saving fails with "Upload Failed"Windows

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.