I'm running into access denied issues when trying to navigate to a UNC path using PowerShell. The problems arise specifically when an upper folder lacks read or list permissions, and this only seems to happen with UNC paths, not local directories. I've tested everything with PowerShell 5.1. Here's a quick overview of my setup: on a remote system, I created a share with subfolders (i.e., \serverabc) and adjusted permissions accordingly.
Here's what works:
- `dir \servera`
- `dir \serverabc`
Both execute fine.
Here's where I hit a wall:
- When I try `dir \serverab`, I get "Access is denied."
While I can use `pushd` to switch to `servera` without issues, attempting `pushd \serverabc` results in another access denied message. It seems clear that I can't get a PowerShell prompt in the "c" folder. Interestingly, these commands work perfectly fine in CMD.EXE. Is there any workaround to make PowerShell behave the same way?
4 Answers
I can't dive into this right now, but I'd suggest trying Process Monitor (procmon) to see what's happening with the permissions when you run those commands. Comparing the outcomes of successful versus failed attempts could give you deeper insight into where things go wrong.
In case it's helpful, a colleague found that `pushd` (which is essentially an alias for `Push-Location`) runs into hurdles with UNC paths when there are permission gaps due to how it's designed on .NET. The framework checks permissions at every folder segment, which can lead to these limitations. This strict enforcement means that PowerShell might not behave like CMD in certain cases. Unfortunately, this design decision makes it less straightforward when working with UNC paths in PowerShell.
Are you considering using the SMBShare module? It might help manage permissions more effectively. Check out the documentation for specifics; it could be beneficial in your scenario.
I’m not sure how the SMBShare module would resolve the issue with "Bypass Traverse Checking." Could you explain your reasoning?
It looks like you might be mixing up how PowerShell and CMD handle UNC paths. CMD typically maps a network drive when you use `pushd`, while PowerShell's `Push-Location` uses .NET APIs which can enforce stricter permission checking at every folder level. You can check your current folder with `Get-Location` to see if you're actually switching folders as expected. Just keep this in mind when using UNC paths; handling them can be a bit tricky in PowerShell.
Thanks for clarifying. I get the differences now, but I was mainly focusing on reproducing the issue conservatively. I’ve tried various approaches, and the problem is consistent. Did it work for you?
Just to add on, PowerShell tries to access the contents of parent folders, as seen in the comparison of permission checks—like when `pushd \serverabc` succeeds or fails based on permissions in folder 'b'. That could shed light on the problem.