How do I list the shared drives and directories of a network computer?

I am on my ComputerA, and ComputerB has shared various drives and directories. How do I get a list of them using JScript code on ComputerA?

I have shared ComputerB's C: Drive as "CDrive", and I can easily list the directories of CDrive using

var cShared = DOpus.FSUtil.ReadDir ("\\\\ComputerB\\CDrive") but I get nothing from the command:

var cShared = DOpus.FSUtil.ReadDir ("\\\\ComputerB")
Again, I can easily list the drives on my own ComputerA using:

var oFSO = new ActiveXObject ("Scripting.FileSystemObject") var eDrives = new Enumerator (oFSO.drives) but this code seems irrelevant to getting a list of the drives and directories shared from ComputerB.

I found this which in a quick test seems to work:

vbscriptwmi.uw.hu/ch31lev1sec2.html#ch31list02

Thanks, jon. That's certainly an advance on my stumbling about. Using it as a clue, I searched Uncle Joe Google on "FileService" and came up with this one, and also with this one in JScript that even catches errors.

The problem is, my network is a peer-to-peer home network, with no "server". All three above use paths beginning:
"WinNT://" + domain + "/" + host + "/Lanmanserver"
which I don't think means much within my network. (I don't even know whether the Registry has anything to do with the settings of a peer-to-peer network.)

Is there an obvious way to adapt these scripts for a peer-to-peer network? I would probably start with the third one, because I am using JScript.

The example Jon linked to has no mention of domains. Just leave out the domain part as in that example.

Should work, regardless of a missing server of some kind - it's just the syntax.

I'm getting there. By inserting "ComputerA", I get a list of all the shares from my own computer to the network. Success!

But when I change to "ComputerB" and try to get its list of all the shares from the other computer, I get an error, which the other two URLs I mentioned report as:
Permission denied: 'GetObject'

  • I have logged on to ComputerB, and can look at its directories with DOpus.
  • I have also used DOpus to turn on Administrator Mode temporarily, and I added @Admin above @Script JScript in the code from the second extra URL.

So there seems to be some permission problem holding things up. Yet DOpus can list the shares from ComputerB with no problems.

What's the result if you run the script directly from an elevated command prompt with cscript.exe, is it any different?

Is ComputerB a Windows machine? I have a feeling this method will only work with real Windows computers, and not e.g. a NAS that just implements Samba.

ANSWER TO JON: I've now also tried to list shares from a third ComputerC on the network — same result. All three computers are running 64-bit Windows 7 Pro SP1. Computer A is an HP Compaq 6305 Pro SFF desktop, Computer B is an HP ProBook 450G1 Notebook, ComputerC is a Toshiba Portege Z30 notebook.

ANSWER TO TBONE: I've pasted the three scripts as standalone *.vbs or *.js files, and run each with cscript.exe using *.bat files (the *.js file needed to be adapted slightly because of the extra "host" item in the path). Same results, whether or not I run the *.bat file as administrator, and whether or not I elevate DOpus to administrator mode — I can list the shares from my computer, but not from the other two.

I copied the *.js, *.vbs and *.bat files to ComputerB and tried to list the shares of ComputerC — same result. The error all the time is
Permission denied: 'GetObject'
except that when I put in a nonsense computer name, or the target computer is turned off, the error message, as expected, is
The server machine does not exist or is unavailable: 'GetObject'

In my home network this does not give permission denied issues, the shares list just fine, but I remember playing quite alot in the file sharing options of win7 to get it working like it used to do on win2k and winxp. I also have the same account on all involved computers (same username, same password), which is essential to get easy access from computer a to b. There is "Credential manager" in win7 to manage/remove cached username/password-combinations, maybe remove some entries and see which is the one that makes DO get through without problems? If it's not the same account and context used by your script then things can get difficult.

Also try to list the shares of the local machine, does that work?

Maybe reading through these gives some more ideas (text links as the forum link handler rendered some invalid):

https://social.technet.microsoft.com/Forums/scriptcenter/en-US/f2955711-4dc5-4150-9f65-60f46f11213c/permission-denied-getobject-when-connecting-to-remote-computer-via-wmi?forum=ITCG https://technet.microsoft.com/en-us/library/cc781010.aspx https://msdn.microsoft.com/en-us/library/aa389290(VS.85).aspx http://www.peetersonline.nl/2008/11/listing-share-permissions-for-remote-shares/

Thanks very much, tbone, for all these details and different approaches. I've worked through the first of the URLs with no success, and I will probably give up at this stage for two reasons:

  1. At the moment, all I am wanting to do is to have the script check whether certain USBs have been stuck into another computer, which I can easily do less elegantly by writing the net view output to a temp file (Net View \ComputerB works!!!) and reading it back in, or by testing the existence of a file or directory that I know is on the USBs.
  2. I will be upgrading to Windows 10 in a few months, when the mysteries of Windows 7 permissions will no longer be relevant.

Nevertheless, I will try to understand the other three URLs you posted — it's all learning.

For the record, I also tried turning off my VPN and turning off the Eset firewall on both computers, and I have deleted my entries in the "Credentials Manager", which I was hardly using anyway. (My family would probably baulk at having my name and password on their computers.) Yes, all three scripts will list ComputerA's shares when run on ComputerA, and ComputerB's shares when run on ComputerB.

It's security vs. getting things done these days, wether it's the computer at home or more complex environments at work. I won't comment on your hope to get rid of windows security mysteries with windows 10! o)

My bet is, that it's related to the impersonation not happening, since it is missing in the examples we've seen here so far (maybe check my links again, there were some examples using impersonation within the "connection string").