How to tell what computer has a file open on a network share?

Question

Environment:

Windows XP sp3, Windows 2003 server

Problem:

We have several dozen kiosk machines each with the same logon name who occasionally and briefly a file on a share. The rate is several locks and releases a minute.

Recently, we have experienced one of the clients locking a file exclusively, and then not releasing the file. 

We can close the file when this happens, but several minutes or longer elapses, and this is an unacceptable outage.

The unreleased lock issue has happened several times in the last month. I've been looking for which kiosk device is responsible for the locking, and to detect it quickly when it happens.

There appears to be a gap in the information we can get from the server:

We can see from various tools:
-What files are open and locked. (many ways)
-What logon has a specifc file open or locked. (many ways)
-That a particular computer generally has a file open. (Shared folders, sessions mmc)

What we cannot see is that a specific computer has a specific file open and locked.

Anyone know of a way to get to this?

Thanks -

Rob

Solution 1

Check out this little freeware util (ShareWatch), I think it'll do what you're looking for.

One of the features listed: "Shows the users and computers that are connected to each share, along with what files are open."

Solution 2

Enter the command line(CMD),

then type : openfiles /query ip of the networkshare

And the username and password may be required.

You can get more information of openfiles on here.

Solution 3

I believe you are going to want to refer back to Sky100's post as he is correct, not in providing you with what you asked, but in providing you with what you need to resolve your issue. You will need to reference the locked ID number via the "openfile /query /v" (verbose) command as it will supply you with the data you need. Search for the file name within the list given, the data will show which item has the read & write enabled, and along with it will provide a specific ID number. No, you may not be able to find which specific system has the file locked, but with the tools provided, you can disconnect that user from the file. Here is a step-by-step to simplify my ramblings.

1) On the fileserver with Administrator rights, do Start > Run > CMD [ENTER]

2) CD Desktop [ENTER] (You'll see why soon.)

3) openfiles /query /v > file.txt [ENTER] (This will create a file on the desktop with a list of all the opened files on the server.)

4) Open the file.txt and search for the line containing both your file name and the Read + Write permissions.

5) Note the ID number on that line and go back to your Command console.

6) openfiles /disconnect /ID [Put ID Number Here] [ENTER]

As long as you have Administrative rights on the file server, it will disconnect that system from the file and assuming your system is automated, should allow things to keep moving along as needed.

References: openfiles /query /? openfiles /disconnect /?

If you are in need of a script or programmed application catered to your system, please feel free to comment and I will provide with contact info, a very low price along with tech. support on my application.

Solution 4

On modern Windows systems,

Get-SMBOpenFile | select path,clientcomputername,clientusername

will do the trick for this. You'll get the local filepath, client computer's IP or hostname, and the AD user who has the file open.

Solution 5

Is the problem you are trying to solve the one you state (ie map the specific client computer (not user) to the locked file) or is it that there is a locking problem that you need to resolve?

If the latter would help then there are two things I would look at:

• Check the AV that is installed on your clients - I've seen multiple Client side AV cause seriously nasty anomolous locking behavior on shares.

• Try disabling opportunistic locking by setting the EnableOpLocks registry value to 0.

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 or 1 Default: 1 (enabled)

This will reduce performance somewhat but should not break anything.

I'd love to see someone actually answer your stated question though - it's an interesting problem.

View more solutions

Comments

[Kcmamu]

Not quite what you are asking, but an alternative approach would be to create a separate account for each system.

[RobW]

Thanks Helvick! Disabling opportunistic locking is an interesting approach. Server I assume?

[Helvick]

Yep it's on the server - this prevents clients requesting opportunistic locking so they can locally cache (parts of) files.

[RobW]

Thanks for this - I tried Sharewatch. In my situation - more than a dozen clients with the same login names - it combines the open files and workstations into the same list. You cant tell which workstation has it open. Also, selecting Properties simply reports that a workstation has x files open, and not their file names. Selecting Properties for the file gives similar info.

[RobW]

Thanks. Openfiles gives largely the same output as net session from the server console. It doesn't give the computer name who has opened the file. I'm looking for a file->computer connection, not a file->user connection.

[RobW]

The performance hit from disabling opportunistic locking would most likely be unacceptable for us. We'll need to look at this in our testbed.

[Helvick]

That is definitely a risk with this - I'd be interested in what you find.

[RobW]

Ha! My issue was to locate the computer from which the file was opened. Do you have any ideas on how to do that? Identifying and closing the file is simple, and there are lots of ways to engineer this outcome. I appreciate the response, and your commercial offer gave me an early morning chuckle ;-)

[Scorpion_God]

My apologies, I wasn't aware that the openfiles process was not the solution. From what you described it seems that would have resolved your need to take a further look at the system as it does not close the file, but just removes that locked setting. In fact, I built the application for my company and it is able to be automated to run every little bit to avoid such complications. I guess that's beside the point, though. To answer your direct question: Yes, there should be a way to audit those systems for their access to that file. Please see my next post for further details.

[Scorpion_God]

Actually, going back and re-reading your post... "We can close the file when this happens, but several minutes or longer elapses, and this is an unacceptable outage." The reason your solution isn't working is because you're CLOSING the file. My and partially Sky100's solution provided earlier does not close the file, but CHANGES the access rights to Read Only. Again, I'm confused as to how openfiles ISN'T the solution you're looking for. Give it a shot before writing it off as a non-solution. If you're not interested in a programmer, create a batch file to run every few minutes.

[Kcmamu]

Hmmm, just re-read your question, and it doesn't quite solve your problem, as it doesn't tell you what file the computer has open.

[RobW]

Mmmm. Apologies, but I dont feel that my question is being addressed by you. I needed help determining which computer held the file open. I'm really interested in determining the computer name. All the rest, while interesting, does not tell me the finite thing I'm after.

[RobW]

Thanks for this. I set auditing on that directory shortly after the initial issue. We have ~150 clients (and not just kiosks) active in that directory. As the problem is intermittent, the signal to noise ratio was huge, and I didnt see a clear way of linking a particular computer to a file event. I'll look at this again. We've already had a couple of design meetings over this. Several topics are on the table, including logon accounts. I'd still like to know what computer is holding a file open :-)

[RobW]

No problem. I appreciate the idea.

[Community]

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.