21

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

RobW
  • 2,766
  • 1
  • 17
  • 22
  • 2
    Not quite what you are asking, but an alternative approach would be to create a separate account for each system. – Bryan Feb 18 '10 at 22:25

11 Answers11

10

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."

alt text

Community
  • 1
techie007
  • 1,892
  • 17
  • 24
  • 1
    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 Feb 03 '10 at 20:35
7

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.

sky100
  • 504
  • 2
  • 3
  • 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 Feb 03 '10 at 22:26
5

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.

Thomas
  • 21
  • 2
  • 1
    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 ;-) – RobW Feb 17 '10 at 15:47
  • 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. – Thomas Feb 18 '10 at 16:06
  • 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. – Thomas Feb 18 '10 at 18:03
  • I'm leaving my solution to your question below as to not waste time in case my understanding of the situation is not thorough. – Thomas Feb 18 '10 at 18:04
  • 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 Feb 19 '10 at 06:27
2

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.

phaedrusschmaedrus
  • 63
  • 5
  • 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](/help/how-to-answer). – Community Dec 31 '21 at 17:53
2

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.

Helvick
  • 19,579
  • 4
  • 37
  • 55
  • Thanks Helvick! Disabling opportunistic locking is an interesting approach. Server I assume? – RobW Feb 03 '10 at 19:26
  • Yep it's on the server - this prevents clients requesting opportunistic locking so they can locally cache (parts of) files. – Helvick Feb 03 '10 at 19:51
  • The performance hit from disabling opportunistic locking would most likely be unacceptable for us. We'll need to look at this in our testbed. – RobW Feb 03 '10 at 22:29
  • That is definitely a risk with this - I'd be interested in what you find. – Helvick Feb 03 '10 at 22:53
2

In my attempt to troubleshoot RobW's problem, and provide an alternate solution, I failed to answer his question.

I believe the solution you are looking for is going to be in setting up Audit policies on that system and then setting that file to audit any access from that particular user. The steps to performing this can vary depending on your network setup, so I'm going to refer you to microsoft's technet link on how to setup different systems to audit.

http://technet.microsoft.com/en-us/library/cc787268(WS.10).aspx

After setting that up, making sure to follow through with setting up the specific file you wish to monitor by attaching the user account as an Auditor, you should be ready to go.

Simply check your Security Event logs in the future and though it will list each system (as they are all using the same username), it should not be difficult to sort through and locate which system currently has Read and Write access to the file.

It may be useful to setup the Security log to clear every few days.

If this doesn't work, it is likely you will need to set the system up per each host name accessing the file, rather than the user name. I believe this is made possible via the Microsoft Management Console.

Again, if you need programming, I'm not a businessman interested in taking loads of your money for some tiny program. I provide quality programming at a price that even an individual would not shy away from. I hope this helps you in resolving your issue.

Thomas
  • 21
  • 2
  • 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 Feb 19 '10 at 07:01
1

I'd also assign different users to different kiosks if possible - it might help you in analyzing other logs...

If that's not possible: Outline of possible solution: A solution could be to run a tool like sysinternals processmonitor with a proper filter (to the file in question) on the kiosks (don't know if you can hide it). There's some command line options you can play with that save the captured data to file.

Collect these from the various kiosks, import them into e.g. Excel and look for the one that wasn't closed...

reiniero
  • 374
  • 1
  • 7
0

What about using the command netstat to determine this?

netstat -an | find ":445"

This should give you the IP addresses of the machines connected.

If you want the hostnames rather than IP addresses, use

netstat -a | find "microsoft-ds"

however this will take longer to execute, especially on busy file servers or domain controllers, as it will have a lot of host lookups to perform.

Also, bear in mind that the results will show inbound, outbound and idle listening ports.

Inbound connections will show the :445 in the left column, outbound show it in the right column.

You can safely ignore any results that state 'LISTENING' and also any lines that show only local IP addresses (e.g. 0.0.0.0 or 127.0.0.1) or the computers own hostname if you don't use the -n option.

For example:

Z:\>netstat -an | find ":445"
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    127.0.0.1:445          127.0.0.1:41764        ESTABLISHED
  TCP    127.0.0.1:445          127.0.0.1:41767        ESTABLISHED
  TCP    127.0.0.1:41764        127.0.0.1:445          ESTABLISHED
  TCP    127.0.0.1:41767        127.0.0.1:445          ESTABLISHED
  TCP    192.168.16.17:445      192.168.16.87:1098     ESTABLISHED
  TCP    192.168.16.17:18055    192.168.16.24:445      ESTABLISHED
  TCP    192.168.16.17:20678    192.168.16.24:445      ESTABLISHED
  UDP    0.0.0.0:445            *:*

The only connected host here is 192.168.16.87. The connections to 192.168.16.24 are outbound. All the other connections are local connections.

Bryan
  • 7,538
  • 15
  • 68
  • 92
0

I remember there was graphical tool within windows to check used shares and locked files.

It should be in the "system tools" under "Computer management" (~ translated from french...), under the name "shared folders".

petrus
  • 5,287
  • 25
  • 42
0

I know this is very old, but ADSI provides the WinNT:// interface, which allows you to access the LANMANSERVER service and query for properties already exposed in the "Shared Folders" mmc snapin. I am currently researching a way to link a host and a user to a open file.

mbrownnyc
  • 1,825
  • 8
  • 30
  • 50
-1

If it was me and I had access to a linux machine on the same subnet... I would do a tcpdump on the share port in question to the box they are holding the file open on.

If you don't have unix, you can still use tcpdump but you have to install it.

from linux... I would do something like this: tcpdump -ieth0 -s0 -X hostname port 1234 | grep -i "nameoffile"

I know that most of the payload is binary... However I would bet good money that they initial header to negotiate authentication for access to the file is in clear text.

This will show you every far end host that connects to that box and where the filename is found within their packet data (if not encrypted or in binary).

Good luck! But from my experience, the following should be used:

1) Shared files is a bad idea! Especially w/ remote systems that could leave a file locked if they drop connection or have slow connections.

2) Access for the shared file will cause a race condition between clients. Wasting valuable tick time.

3) If you MUST use a shared file... Create different usernames for each remote site so you can properly debug.

Best scenario... get rid of file and merge into SQL or create a webservice that allows the clients to access the file or data.

++Todd

Todd
  • 1