Can't delete files on NTFS file system - Windows Server (2024)

This article describes why can't delete a file or a folder on an NTFS file system volume. It also provides help to solve this issue.

Original KB number: 320081

Cause 1: The file uses an ACL

You can't delete a file if the file uses an Access Control List (ACL). To resolve this issue, change the permissions on the file. You may have to take ownership of the files to change the permissions.

Administrators have the implicit ability to take ownership of any file, even if they haven't been explicitly granted any permission to the file. File owners have the implicit ability to modify file permissions, even if they aren't explicitly granted any permissions to the file. So, you may have to take ownership of a file, give yourself permissions to delete the file, and then delete the file.

You can't use certain security tools to display or to modify permissions because the file has a non-canonical ACL

To work around this issue, use another tool (for example, a later build of Cacls.exe).

The Access Control Entries (ACEs) in an ACL have a certain preferred sequence depending on their type. For example, ACEs that deny access typically come before ACEs that grant access. However, nothing prevents a program from writing an ACL that has ACEs in any arbitrary sequence. In some earlier versions of Windows, issues occurred when Windows tried to read these non-canonical ACLs. Sometimes you can't modify these ACLs correctly by using the Microsoft Windows Explorer graphical security editor. This issue has been corrected in later versions of Windows. If you experience this issue, use the most recent version of Cacls.exe. Even if you can't display or edit an ACL in place, you can write a new ACL to gain access to the file.

Cause 2: The file is being used

You can't delete a file if the file is being used. To resolve this issue, determine the process that has the open handle, and then close that process.

Depending on how the file is opened, you may not be able to delete a file that's in use. For example, the file is open for exclusive access instead of shared access. You can use various tools to determine the processes that have open handles to files whenever you want.

The symptoms of this issue may vary. You can use the Delete command to delete a file. But the file isn't deleted until the process that has the file open releases the file. Additionally, you may not be able to access the Security dialog box for a file that's pending deletion. To resolve this issue, determine the process that has the open handle, and then close that process.

Cause 3: File system corruption is preventing access to the file

You can't delete the file if the file system is corrupted. To resolve this issue, run the Chkdsk utility on the disk volume to correct any errors.

The following reasons can corrupt the file system and put files in a problematic state:

• Bad sectors on the disk
• Other faulty hardware
• Software bugs

Typical operations may fail in various ways. When the file system detects corruption, it logs an event to the event log and you typically receive a message that prompts you to run Chkdsk. Depending on the nature of the corruption, Chkdsk may or may not recover file data. However, Chkdsk returns the file system to an internally consistent state.

Cause 4: Files exist in paths that are deeper than MAX_PATH characters

You can't open, edit, or delete a file if there are issues with the file path.

Resolution 1: Use an autogenerated 8.3 name to access the file

To resolve this issue, you may want to use the autogenerated 8.3 name to access the file. This resolution may be the easiest resolution if the path is deep because the folder names are too long. If the 8.3 path is also too long or if 8.3 names have been disabled on the volume, go to Resolution 2. For more information about disabling 8.3 file names on NTFS volumes, see How to disable the 8.3 name creation on NTFS partitions.

Resolution 2: Rename or move a deep folder

Rename the folder so that the target files that are deeper than the MAX_PATH no longer exist. If you do so, start at the root folder or any other convenient place. Then rename folders so that they have shorter names. If this step doesn't resolve this issue, for example, if a file is more than 128 folders deep, go to Resolution 4.

Resolution 3: Map a drive to a folder in the structure of the path

Map a drive to a folder inside the structure of the path of the target file or folder. This method shortens the virtual path.

For example, suppose you have a path that is structured as follows:

\\ServerName\SubfolderName1\SubfolderName2\SubfolderName3\SubfolderName4\...

In this path, the total character count is over 255 characters. To short the length of this path, to 73 characters, map a drive to SubfolderName4.

If resolutions 1, 2, and 3 aren't convenient or don't resolve the issue, create a network share that's as deep in the folder tree as you can. Then rename the folders by accessing the share.

Resolution 5: Use a tool that can traverse deep paths

Many Windows programs expect the maximum path length to be shorter than 255 characters. These programs only allocate enough internal storage to handle these typical paths. NTFS doesn't have this limit, and it can hold much longer paths.

You may experience this issue if you create a share at some point in your folder structure that's already fairly deep, and then create a deep structure below that point by using the share. Some tools that operate locally on the folder tree may not be able to traverse the whole tree starting from the root. You may have to use these tools in a special way so that they can traverse the share. The CreateFile API documentation describes a method to traverse the whole tree in this situation.

Typically, you can manage files by using the software that creates them. If you have a program that can create files that are deeper than MAX_PATH, you can typically use that same program to delete or manage the files. You can typically delete files that are created on a share by using the same share.

Cause 5: The file name includes a reserved name in the Win32 name space

If the file name includes a reserved name in the Win32 name space, such as lpt1, you can't delete the file. To resolve this issue, use a non-Win32 program to rename the file. You can use a POSIX tool or any other tool that uses the appropriate internal syntax to use the file.

Additionally, you can use some built-in commands to bypass the typical Win32 reserved name checks if you use a particular syntax to specify the path of the file.

If you open a handle to a file by using the typical Win32 CreateFile mechanism, certain file names are reserved for old-style DOS devices. For backward compatibility, these file names aren't permitted, and they can't be created by using typical Win32 file calls. This issue isn't a limitation of NTFS.

You can use a Win32 program to bypass the typical name checks that are done when a file is created or deleted by using the same technique that you use to traverse folders deeper than MAX_PATH. Additionally, some POSIX tools aren't subject to these name checks.

Cause 6: The file name includes an invalid name in the Win32 name space

You can't delete a file if the file name includes an invalid name. For example, the file name has a trailing space or a trailing period, or the file name is made up of a space only. To resolve this issue, use a tool that uses the appropriate internal syntax to delete the file. You can use the "\\?\" syntax with some tools to operate on these files. Here's an example:

del "\\?\c:\<path_to_file_that contains a trailing space.txt>"

The cause of this issue is similar to Cause 4. If you use typical Win32 syntax to open a file that has trailing spaces or trailing periods in its name, the trailing spaces or periods are stripped before the actual file is opened. For example, you have two files in the same folder named AFile.txt and AFile.txt , note the space after the file name. If you try to open the second file by using standard Win32 calls, you open the first file instead. Similarly, if you have a file whose name is just a space character and you try to open it by using standard Win32 calls, you open the file's parent folder instead. In this situation, if you try to change security settings on these files, you either may not be able to do so, or you may unexpectedly change the settings on different files. If this behavior occurs, you may think that you have permission to a file that actually has a restrictive ACL.

Combinations of causes

Sometimes, you may experience combinations of these causes. It can make the procedure to delete a file more complex. For example, if you log on as the computer's administrator, you may experience a combination of Cause 1 (you don't have permissions to delete a file) and Cause 5 (the file name contains a trailing character that causes file access to be redirected to a different or nonexistent file), and you can't delete the file. If you try to resolve Cause 1 by taking ownership of the file and adding permissions, you still may not be able to delete the file, because the ACL editor in the user interface can't access the appropriate file due to Cause 6.

In this situation, you can use the Subinacl utility with the /onlyfile switch (this utility is included in the Resource Kit) to change ownership and permissions on a file that's otherwise inaccessible. Here's an example:

subinacl /onlyfile "\\?\c:\<path_to_problem_file>" /setowner= domain\administrator /grant= domain\administrator=F

This sample command line modifies the C:\<path_to_problem_file> file that contains a trailing space so that the domain\administrator account is the owner of the file and this account has full control over the file. You can now delete this file by using the Del command with the same "\\?\" syntax.