I've got some leftover Windows update temporary folders (they have GUID-ish names) on the root of the system drive. I'm trying to clean these up, but am getting the following behavior upon deletion request through Windows Explorer:

  1. "You'll need to provide administrator permission to delete this folder"
  2. Click
  3. "You need permission to perform this action" + "You require permission from \ to make changes to this file"

I have taken ownership of the folder, along with all its child items, and I have full control permissions on the folder, and all its child items.

Every other thread on this issue says that you need to take ownership and add full control permissions to yourself, but this obviously has not done the trick.

Asked differently: Why do I need permission from myself to perform this file operation?

FWIW, using the "Unlocker" tool works around the problem, but I'm interested in getting to the root cause, rather than hacking it.

  • What version of Windows NT are you using? – JdeBP Jan 31 '12 at 13:31
  • 99% chance you have a locked file. Run Process Explorer to find the offending process and kill the file handle. – John Homer Jan 10 '13 at 20:44
  • This is an excellent Microsoft help page on the issue. My problem was files that had started with a name component "Con" - which is a reserved name in Windows. I used the "del \\?\..." syntax to delete them, as per the article. – davidbak Jan 16 at 0:14

FWIW, using the "Unlocker" tool works around the problem

This hints that there are locked files in those folders. That means that there was an active process with an open handle to something in there. A file with an open handle can't be deleted. Usually, if you can't track down what's causing this, a reboot will kill any stray processes that might not have released those files.

This doesn't sound like it really has anything to do with file permissions, but Windows does give you a generic Access Denied message when attempting to modify a locked file.

  • Excellent -- I'll grab Sysinternals Process Explorer or handle.exe and see if anything has a file handle open in that folder. I should have thought of that, thanks. – Trevor Sullivan Jan 30 '12 at 16:29
  • Ok, so I ran handle.exe > c:\handle.txt, used Notepad2 to search the log for one of the folder names, and it can't find anything. So, no dice, sorry. – Trevor Sullivan Jan 30 '12 at 16:30
  • Use the search feature in Process Explorer. Make sure you run it elevated (Run as administrator) or it won't see all the open file handles. – John Homer Jan 10 '13 at 20:43

I had this exact issue on files hosted on a Windows 2008 R2 file server. I tried several of the fixes listed here (as well as from other sites), but none worked. In most cases, I received permission denied messages when I attempted my fix. On a whim, I looked at the open files on the server in question. The user who originally reported the problem had the files open on their PC, but had since totally closed all file applications (Word, Acrobat and Excel in this case).

According to the File Server's Open Files list (Server Computer Management > System Tools > Shared Folders > Open Files, many of the files that were in the folders to be deleted that were causing the errors were still open by that user.

I performed a force close by selecting the files, right clicking and selecting "Close Open File", then we were able to delete the folders with no more issues.


I had the same issue with server 2012 R2 What I did was: show hidden files en system files, gave myself full control of recycle bin. Somehow I did not have rights to delete the recycle bin within this folder. Once I gave myself full control over recycle bin I was able to delete the whole folder incl. the recycle bin. Hope this helps others



I found that the problem had nothing to do with permissions. It may have been a problem with long file names. To solve, I deleted individual files within the folder structure. Once those files had been deleted, I had no problem deleting the folder structure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.