PowerShell Test-Path returns False when testing a network share
Asked Answered
K

8

12

The user has appropriate permissions to read the share, and the share maps properly. This issue seems to happen only in PowerShell v2.0.

If I remove all mapped drives, remap one drive, and run Test-Path:

net use /delete * /y
net use G: \\somefileserver\share
Test-Path G:\

Test-Path returns False, even though the drive is clearly mapped, and I can access it through Windows Explorer.

If I close the PowerShell session, and open a new session, Test-Path returns True, as it should. Any ideas on, (A): what could be causing this, and how do I make it work properly? or (B): Is there another way to test for the existence of a network drive besides Test-Path? I am attempting to write a logon script to map user's network drives and this behavior is driving me insane.

Kaki answered 14/3, 2014 at 2:14 Comment(1)
Just for the record: this works fine in PS v3.0. Starting the PS elevated as administrator makes a difference though in any version. Drives mapped as standard user won't be visible in the elevated PS.Strip
S
11

If the Test-Path cmdlet is truly buggy, then I'd suggest using the Exists() method on the System.IO.Directory .NET class.

[System.IO.Directory]::Exists('G:\'); # This returns $true for me
Submicroscopic answered 14/3, 2014 at 2:22 Comment(1)
Where do I loose is, when trying this above out? Tried it out and it didn't work with a UNC path, but local patch it worked But I do think it's me not fully understanding the Q and A...?Gale
G
15

I do think I found the answer with this:

Test-Path $('filesystem::\\Server\share$\install.wim')
Gale answered 10/4, 2017 at 13:52 Comment(1)
The sub-expression is not necessary, i.e. Test-Path 'filesystem::\\Server\share$\install.wim' is finePatrol
S
11

If the Test-Path cmdlet is truly buggy, then I'd suggest using the Exists() method on the System.IO.Directory .NET class.

[System.IO.Directory]::Exists('G:\'); # This returns $true for me
Submicroscopic answered 14/3, 2014 at 2:22 Comment(1)
Where do I loose is, when trying this above out? Tried it out and it didn't work with a UNC path, but local patch it worked But I do think it's me not fully understanding the Q and A...?Gale
T
8

To validate a UNC, use:

[bool]([System.Uri]$path).IsUnc
Tain answered 19/11, 2014 at 13:28 Comment(2)
This does not actually test the path - it simply tests whether the parsed string is a UNC path.Jillene
To validate parameter, I would use [ValidateScript({(test-path $_) -and ([System.Uri]$_).IsUnc})]. Just saying because this could help someone. Thanks @DanAtkinsonAlkane
H
1

I had the exact same problem trying two network paths like this:

$verif_X = Test-Path "X:\"
$verif_S = Test-Path "S:\"
if($verif_X -and $verif_S){
    Write-Host "X: and S: network paths found"
}
else{
    Write-Host "Not all network paths found"
}

... At first, I always got > "Not all network paths found" which seemed really strange to me...

Then I tried to put those paths in simple quotes (') and searched for an existing folder inside those both network paths like this:

$verif_X = Test-Path 'X:\ISOs'
$verif_S = Test-Path 'S:\Scripts'

And then

if($verif_X -and $verif_S){[..]}

condition is accepted..

I think the Test-path cmdlet is a bit buggy as we enter only the first letter of a network path... but like this I do not get errors any more...

Hypothesis answered 7/11, 2017 at 15:28 Comment(0)
H
1

I found also this answer which can be found here: It says that one can use the .NET framework to do so:

$path = "C:\text.txt"
if([System.IO.File]::Exists($path)){
    # file with path $path exists
}

Works fine if its a file. To find a folder, use:

$path = x:\
if([System.IO.Directory]::Exists($path)){
    # file with path $path exists
}
Hypothesis answered 29/6, 2022 at 11:21 Comment(0)
S
0

For me the only way to fix it was to use the full UNC, rather than the share name.

So instead of \\server\share I used \\server\c$\sharedir.

Another issue I ran into was when using Import-Module sqlps, I had to make sure to CD back into the file system and then the PowerShell commands worked normally.

Setscrew answered 1/3, 2017 at 14:2 Comment(1)
\\server\share and \\server\c$\shareddir are not the same thing, though. They have the same NTFS ACL, but the share ACLs are different.Antonio
M
0

SHORT ANSWER

if(-Not(Test-Path "filesystem::\\$server\c$")) {Write-Error "Server not found: $server"; continue} If Test-Path fails unexpectedly then make sure SMB2=1 (or other SMB setting) is set on both client and target server.

MORE INFO

IMPORTANT SMB NOTE: Both current system and target system must have at least on common SMB protocol enabled for Test-Path to succeed. (SMB2 or later strongly recommended.) For example, if target has SMB1 enabled + SMB2 disabled and client has only SMB2 enabled then logic above will return "Server not found...". This threw me off track until I finally checked my target server (Win7) and found it had SMB2=0 (disabled) and no entry for SMB1 (enabled by default). I fixed by setting SMB2=1 per article below.

SMB OS-specific and scripting details: https://support.microsoft.com/en-us/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server

Excerpt: Win8/Win20012

Detect: Get-SmbServerConfiguration | Select EnableSMB1Protocol
Disable:    Set-SmbServerConfiguration -EnableSMB1Protocol $false
Enable: Set-SmbServerConfiguration -EnableSMB1Protocol $true

Excerpt: Win7/Win2008R2Server

Detect:
Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}
Default configuration = Enabled (No registry key is created), so no SMB1 value will be returned

Disable:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 –Force

Enable:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 1 –Force

Code sample: Copy-Item a folder (recursive) only if target server exists

$scriptRootPath="." 
$scriptToolsPath="$scriptRootPath\Tools" 
$targetServerList="$scriptToolsPath\DeployServerList-INT-POC.txt"   #DeployServerList-INT.txt, DeployServerList-QA.txt, DeployServerList-PROD.txt
$stageTargetDrive="c"
$stageFolderPath="$stageTargetDrive$\staging"

$VerbosePreference="Continue"                                       #"SilentlyContinue" (default), "Continue", "Stop", "Inquire"
$InformationPreference="Continue"

Write-Host "Getting list of servers from $targetServerList to stage deployment files to..."
    $serverList = (get-content "$targetServerList")
    Write-Verbose "scriptToolsPath=$scriptToolsPath"
    Write-Verbose "serverlist=$serverList"
    Write-Verbose "stageFolderPath=$StageFolderPath"

Write-Host -Separator "-"
Read-Host -Prompt "READY TO STAGE FILES: Check info above, then press Enter to continue (or Ctrl+C to exit)."
Write-Host "-------------------------------------------------"

Write-Host "Staging files to $stageFolderPath on each target server..."
foreach ($server in $serverlist) {
    # Input validation
    if([string]::IsNullOrWhiteSpace($server)) {continue}
    if($server.StartsWith("#")) {Write-Verbose "Comment skipped: $server"; continue}    # Skip line if line begins with hashtag comment char
    Write-Verbose "Testing filesystem access to $server..."
    if(-Not(Test-Path "filesystem::\\$server\$stageTargetDrive$")) {Write-Error "Server not found: $server"; continue}
        # TIP: If Test-Path returns false unexpectedly then check if SMB2 is enabled on target server, check SMB1 disabled for both src and target servers.

    Write-Verbose "Staging files to $server..."
    Copy-Item ".\" -Destination "\\$server\$stageFolderPath" -Recurse -Force -ErrorAction Continue
    Write-Information "Files staged on $server."
} 
Minardi answered 14/5, 2019 at 23:33 Comment(0)
S
0

I had this issue today, and found this issue.

For me, the error occurred in PowerShell ISE x(86), but not in the ISE 64-bit.

We use the BizTalk PowerShell extensions, which only work in x(86), so sometimes on my servers I default to using that.

The solution of using

[System.IO.Directory]::Exists($dirname); 

worked for me on both x86 and 64 bit.

Southernly answered 13/7, 2023 at 19:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.