T4RH33L
T4RH33L

Reputation: 179

Get-ChildItem Cannot Find Path Because It Does Not Exist

I'm working on a script to get my ACLs for all of the shares in my network. I have three separate UNC paths that I am running this on. Two of the three are working perfectly, returning all child items and permissions and such. However, the third UNC path is returning the following error:

Get-ChildItem : Cannot find path '\\storagesrvr' because it does not exist.

I have verified that the location is available by using Explorer. What I find interesting is that if I use GCI on any of the sub-shares of that path, it works. What could possibly be preventing GCI from detecting the root of the share?

EDIT (as requested from comments): The other two shares that I had no issues with were named like \\networkpath\share. But because I was only looking at the root, GCI was not working.

Upvotes: 6

Views: 19634

Answers (3)

Mathias R. Jessen
Mathias R. Jessen

Reputation: 174465

As I mentioned in the comments \\computername is only a partial UNC path (check the UNC grammar in the [MS-DTYP] Windows Data Type specification).

Explorer "knows" this, and so it does some black magic in the background to allow you to browse the shares on the remote computer.

You can emulate this, by querying the Win32_Share WMI instances on the remote machine:

foreach($Share in Get-WmiObject Win32_Share |?{$_.Name -ne 'IPC$'}){
    Get-ChildItem "\\$($Share.__SERVER)\$($Share.Name)"
}

Upvotes: 7

Duken.Jr
Duken.Jr

Reputation: 116

You can list shares by calling:

net view \\<computername>

source: PowerShell Get List Of Folders Shared

Upvotes: 2

Bill_Stewart
Bill_Stewart

Reputation: 24525

The error message is literally correct. \\storageserver is not a path. It is two backslashes followed by a computer name.

Append a share name to it, and it becomes a path; e.g. \\storageserver\sharename.

Upvotes: 1

Related Questions