A PowerShell script failing to access a perfectly valid SMB network share is a classic DevOps “gotcha” that causes headaches for junior engineers and weary sighs from seniors.

That SMB Share Exists, I Swear! Why Your PowerShell Script Can’t See It

I remember it vividly. It was 3 AM, and a critical deployment script for our `prod-db-01` cluster was failing. The error was maddeningly simple: Cannot find path '\\file-cluster-01\deploy-packages\latest.zip' because it does not exist. But it *did* exist. I could browse to it in Explorer. I could `dir` it from a `cmd` prompt. Yet, PowerShell, running as our deployment agent, was completely blind. This wasn’t a permissions issue; it was a context issue—a rite of passage every PowerShell automator goes through. If you’ve hit this wall, don’t worry. We’ve all been there.

First, The “Why”: PowerShell Providers vs. The Old World

Before we fix it, you need to understand the root cause. Unlike the classic Command Prompt (`cmd.exe`), which lives and breathes drive letters and UNC paths, PowerShell operates on a more abstract concept called Providers. You have a FileSystem provider (for `C:`), a Registry provider (for `HKLM:`), an Environment provider (`Env:`), and so on. When you run `Set-Location` (or its alias `cd`), you’re telling a specific provider to change its current working directory.

The problem is that simply running `Set-Location \\server\share` doesn’t permanently change the shell’s context in the way you might expect. The FileSystem provider understands the path for a one-off command like `Get-ChildItem \\server\share`, but it doesn’t treat that remote path as its “home base” for subsequent commands. This is especially true in non-interactive scripts, like a Scheduled Task or a CI/CD pipeline, which have zero context of any drives you might have mapped in your own user session.

Solution 1: The Quick Fix (Push-Location)

This is my go-to for simple, self-contained tasks within a larger script. `Push-Location` saves your current directory, jumps to the new one (including UNC paths!), lets you do your work, and then `Pop-Location` zaps you right back where you started. It’s clean, transactional, and easy to read.

Imagine your script needs to grab a log file from a share:

Write-Host "Starting log retrieval..."
Push-Location -Path "\\file-cluster-01\backups"

# Now we are "in" the remote directory
Write-Host "Successfully changed directory to the remote share."
Get-ChildItem -Filter "*.log" | ForEach-Object {
    Write-Host "Found log file: $($_.Name)"
    Copy-Item -Path $_.Name -Destination "C:\temp\archive\"
}

# IMPORTANT: Pop back to your original location
Pop-Location
Write-Host "Log retrieval complete. Returned to original directory."

When to Use This:

• For short, specific operations on a network share inside a larger script.
• When you don’t want to manage a persistent drive mapping.

Solution 2: The Permanent Fix (New-PSDrive)

If your script needs to repeatedly access the same network location, or if you’re dealing with a legacy application that absolutely requires a drive letter, creating a temporary PowerShell drive (`PSDrive`) is the most robust and “correct” solution. It’s the DevOps equivalent of mapping a network drive, but it’s done programmatically and only exists for the life of your script.

Pro Tip: Never, ever rely on drive letters mapped in your interactive Windows session for an automated script. The account running the script (like `NT AUTHORITY\SYSTEM` for a scheduled task) has no idea what your personal `X:` drive is. Always define your context *within the script*.

Here’s how you’d map a drive, use it, and then clean it up:

$sharePath = "\\file-cluster-01\deploy-packages"
$driveName = "P" # Pick a letter you know is free

if (Test-Path -Path "${driveName}:") {
    Write-Error "Drive letter ${driveName}: is already in use!"
} else {
    Write-Host "Mapping ${sharePath} to ${driveName}: drive..."
    New-PSDrive -Name $driveName -PSProvider FileSystem -Root $sharePath

    # Now you can use P: like any other drive
    Set-Location "${driveName}:"
    $latestPackage = Get-ChildItem -Path ".\latest.zip"
    Expand-Archive -Path $latestPackage.FullName -DestinationPath "C:\inetpub\wwwroot\myapp"

    # Best Practice: Clean up after yourself!
    Write-Host "Removing PSDrive ${driveName}:"
    Remove-PSDrive -Name $driveName
}

When to Use This:

• When your script interacts heavily with a specific share.
• When you need to pass a drive-letter path to an external command or utility.
• For better readability in complex scripts.

Solution 3: The ‘Nuclear’ Option (Invoke cmd.exe)

Let’s be real: sometimes you’re in a corner. You’re dealing with a crusty old `.exe` that refuses to understand UNC paths, and for some reason, `New-PSDrive` isn’t working in your execution environment. I consider this a “hacky” last resort, but it’s a tool in the toolbox. You can shell out to the old `cmd.exe` to run a command for you.

The big downside is that you lose all the goodness of PowerShell—objects, error handling, and the pipeline. You’re just firing and forgetting a plain text command.

# An example using the old 'robocopy' utility
$source = "\\file-cluster-01\source"
$destination = "C:\destination"
$arguments = @(
    $source,
    $destination,
    "/E", # Copy subdirectories, including empty ones
    "/R:2", # Retry twice on errors
    "/W:5"  # Wait 5 seconds between retries
)

Write-Host "Calling Robocopy via cmd.exe..."
Start-Process -FilePath "robocopy.exe" -ArgumentList $arguments -Wait -NoNewWindow

You can even get more direct with `cmd /c` for very simple commands:

cmd /c "echo . > \\file-cluster-01\monitoring\heartbeat.txt"

When to Use This:

• When all else fails.
• When interfacing with legacy command-line tools that are picky about paths.
• For “fire-and-forget” operations where you don’t need to process the output.

Conclusion

Nine times out of ten, your problem with PowerShell and SMB shares comes down to context. Your script doesn’t inherit the convenience of the interactive shell you’re testing in. By explicitly setting the context with `Push-Location` or creating a dedicated `PSDrive`, you make your automations more reliable, readable, and resilient. Save the `cmd` escape hatch for when you truly need it, and you’ll be writing robust scripts that don’t wake you up at 3 AM.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions