Who Has This File Open? How to Find Out on a Windows Network

The Actual Problem

Word, Excel or your design app tells you the file is in use, and names the culprit as "another user". In an office of twelve people that is not an answer, it is a scavenger hunt. You walk the floor asking who has the quarterly report open, and by the time you find them you have lost twenty minutes.

Windows does know who. It just does not put the name in that dialog. Here are three ways to get it, in order of how quickly they work.

Method 1 — Read the Hidden Owner File (10 seconds)

Office writes a small hidden file next to the document while it is open, named after the document with a ~$ prefix. Quarterly Report.xlsx gets ~$Quarterly Report.xlsx, in the same folder.

That file contains the name of whoever opened it.

1. Open the folder containing the document.
2. In File Explorer, go to View → Show → Hidden items (Windows 11) or tick Hidden items on the View ribbon (Windows 10).
3. Find the ~$ file matching your document.
4. Open it with Notepad.

You will see a short run of characters with a name in it — usually the Windows username or the display name that person set in Office. That is your answer.

A caveat worth knowing: the name stored there is whoever first opened the file, and Office truncates it. It is not always the full name, and if the file was opened read-only by several people it may not be the person actually holding the write lock. It is right often enough to be the first thing to try.

Method 2 — Computer Management on the Host (the reliable one)

This is the method most people never learn, and it is the one that actually answers the question. It has to be run on the machine that hosts the share, not on yours.

1. On the host PC, press Win + X and choose Computer Management.
2. Expand System Tools → Shared Folders → Open Files.

You get a live list of every file currently open across the network, with the user account that has it, the number of locks, and the access mode. Sort by the file name and you have your person.

From the same screen you can right-click an entry and choose Close Open File to force the handle shut.

Do that carefully. Force-closing does not tell the other person's application anything. Their Word or Excel still believes it owns the file, and their next save can either fail outright or write a stale copy over newer content. Use it when someone has genuinely gone home with a file open, not to jump a queue while a colleague is still typing.

The command-line equivalent, run on the host in an elevated prompt:

openfiles /query /fo table

If it reports that the object list is not enabled, switch it on once and reboot:

openfiles /local on

Method 3 — Ask the Host Remotely

If you administer the machines, you do not need to walk over. From your own elevated prompt:

openfiles /query /s HOSTNAME /fo table

Or in PowerShell, which is friendlier to read and filter:

Get-SmbOpenFile | Select-Object ClientUserName, Path

Get-SmbOpenFile needs to run on the host too, but it works nicely over PowerShell Remoting and is far easier to filter than the table output.

When Nobody Has It Open

Sometimes every method above comes back empty and the file still refuses to open. That is a stale lock, and it is common. The usual causes:

• Word or Excel crashed. The application died without cleaning up its ~$ file, so the document still looks claimed.
• A machine went to sleep or lost the network mid-edit, leaving the handle open on the host until the session times out.
• The document was opened from a preview pane. File Explorer's preview can hold a handle on the file without any window being obviously open.

Fixes, in the order worth trying:

1. Delete the ~$ file. With the document genuinely closed everywhere, deleting the hidden owner file clears the claim. This is safe — it is a lock marker, not your data.
2. Close the handle from Computer Management as above.
3. Turn off the Preview pane in File Explorer (View → Show → Preview pane) and try again. If this fixes it, the preview pane was the "other user" all along.
4. Restart the Server service on the host as a last resort. It drops every network handle at once, so make sure nobody is mid-save:

Restart-Service LanmanServer -Force

The Read-Only Trap

A file that opens read-only without any warning is the same problem wearing a different hat. Office falls back to read-only when it cannot get a write lock, and it does not always explain why. If a document opens read-only for one person and normally for everyone else, work through the same three methods — someone or something has the write lock.

Related, and a genuine source of confusion: a file marked read-only as a file attribute behaves the same way but has nothing to do with the network. Right-click the file, choose Properties, and check whether Read-only is ticked before blaming the share.

Why Windows Will Not Just Tell You

It is worth understanding, because it explains why this keeps happening.

There is no central registry of who has what open. The lock lives in two places that do not know about each other: an application-level marker (the ~$ file, written by Office, sitting next to your document) and an SMB file handle on the host (managed by Windows, visible only in Computer Management on that machine).

The dialog you see comes from the application, and the application only knows what it can read from the ~$ file. When that file is missing, truncated, or was written by a different version of Office, you get "another user" — because that is genuinely all it knows.

Nothing about this is going to improve. It is a design from an era when the file server was a server, administered by someone whose job that was.

If You Would Rather Not Play Detective

The reason this article exists is that the information is scattered across three tools and none of them is where the error appears.

Tools that do not use SMB for the transfer do not inherit this particular mess, because there is no ~$ marker and no separate handle table to reconcile. Oxolan takes that approach: when someone has a shared file open, the other machines show it as held and show which machine is holding it, rather than "another user".

To be straight about what that is and is not: it is checkout-style coordination for a small office — one editor at a time, with the holder named — and it is best-effort rather than a guarantee. If your work genuinely cannot tolerate two people ever touching one file, a document management system or version control is the right tool, and we would rather say so than oversell it.

Related Guides

• Error 0x80070035 — the network path was not found
• Error 0x80070043 — Windows cannot access the share
• Windows file sharing keeps disconnecting
• Why Windows file sharing has gotten worse over time
• Setting up a shared workspace without IT support