Getting 'Access Denied' when running Get-ChildItem even as an administrator

Question

I'm trying to delete files like desktop.ini, Thumbs.db, etc, using the following powershell command to recurse over a root directory on an external hard drive:

Get-ChildItem -Path . -Include Thumbs.db, Picasa.ini, .picasa.ini, AlbumArt_*.jpg, AlbumArtSmall.jpg, desktop.ini, Folder.jpg -Recurse -Name -Force | Remove-Item -Force

But I keep getting the following error:

Get-ChildItem : Access is denied
At line:1 char:1
+ Get-ChildItem -Path . -Include Thumbs.db, Picasa.ini, .picasa.ini, Al ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.GetChildItemCommand

The command prompt in which I start powershell (to run the above command) is run as an administrator, so I don't know why I'm getting 'Access Denied' still.

Even if I remove the Remove-Item part to just list the files matching those filenames, I still get the above error.

I also tried adding -Verbose tag to see if the folder which is throwing 'Access Denied' gets listed, but it does not.

Any ideas how I can get the above command to work ?

Answer 1

Most likely, you're receiving these errors when recurion attempts to access one of the various directory junctions that exist for backward compatibility with older programs. Their names correspond to the system foilders in older versions of Windows while their targets point to the current equivalent. Some are system-wide:

Path	Target
C:\Documents and Settings	C:\Users
C:\Users\Default User	C:\Users\Default
C:\ProgramData\Application Data	C:\ProgramData
C:\ProgramData\Desktop	C:\Users\Public\Desktop
C:\ProgramData\Documents	C:\Users\Public\Documents
C:\ProgramData\Start Menu	C:\ProgramData\Microsoft\Windows\Start Menu
C:\ProgramData\Templates	C:\ProgramData\Microsoft\Windows\Templates
C:\Users\All User\Application Data	C:\ProgramData
C:\Users\All Users\Desktop	C:\Users\Public\Desktop
C:\Users\All Users\Documents	C:\Users\Public\Documents
C:\Users\All Users\Start Menu	C:\ProgramData\Microsoft\Windows\Start Menu
C:\Users\All Users\Templates	C:\ProgramData\Microsoft\Windows\Templates

While some are per-user:

Path	Target
$env:UserProfile\Application Data	$env:UserProfile\AppData\Roaming
$env:UserProfile\Cookies	$env:UserProfile\AppData\Local\Microsoft\Windows\INetCookies
$env:UserProfile\Local Settings	$env:UserProfile\AppData\Local
$env:UserProfile\My Documents	$env:UserProfile\Documents
$env:UserProfile\NetHood	$env:UserProfile\AppData\Roaming\Microsoft\Windows\Network Shortcuts
$env:UserProfile\PrintHood	$env:UserProfile\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
$env:UserProfile\Recent	$env:UserProfile\AppData\Roaming\Microsoft\Windows\Recent
$env:UserProfile\SendTo	$env:UserProfile\AppData\Roaming\Microsoft\Windows\SendTo
$env:UserProfile\Start Menu	$env:UserProfile\AppData\Roaming\Microsoft\Windows\Start Menu
$env:UserProfile\Templates	$env:UserProfile\AppData\Roaming\Microsoft\Windows\Templates

As to why Access Denied errors are thrown when attempting to view the contents in Explorer or via Get-ChildItem, this is due to the ACL (Access Control List) for these including

• Deny EVERYONE List folder/read data

As the linked reference explains:

These junction points can be identified as follows:

• They have the FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_HIDDEN, and FILE_ATTRIBUTE_SYSTEM file attributes set.

• They also have their access control lists (ACLs) set to deny read access to everyone.

Applications that call out a specific path can traverse these junction points if they have the required permissions. However, attempts to enumerate the contents of the junction points will result in failures. It is important that backup applications do not traverse these junction points, or attempt to backup data under them, for two reasons:

• Doing so can cause the backup application to back up the same data more than once.

• It can also lead to cycles (circular references).

As mentioned above, it is only read (List folder/read data) permissions that are denied. So while attempting to view Documents and Settings will throw an error, you traverse these junctions by typing in the Adddress Bar or a Run dialog. For example (assuming subfolder names are valid):

• C:\Documents and Settings\%UserName%
• %UserProfile%\My Documents\Manuals
• %UserProfile%\My Documents\My Music\Abba

will all work. You can also access files within the target folder:

• %UserProfile%\My Documents\ToDo.txt

Indeed, when you examine Effective Access from the advanced Security dialog, you can do everythihg but view/list the contents:

Answer 2

I ran into a similar situation. One single 'corrupt' file (refused to allow me to modify permissions) was causing the whole recurse to fail with the "access is denied" error. I went folder by folder under C until I got the error, then repeated for each additional set of folders until I identified the offending file. It turned out to be a log file for Splunk Universal Forward which has permissions corrupted (could not see permissions, or take permissions/ownership). Booting into safe mode and deleting the file resolved the issue.