NTFS Blind Spot: Folder Protection (Non-Recursive) from Accidental Deletion in Windows (Docker-Friendly)

Seneelya — Tue, 26 May 2026 15:56:19 +0000

Hey everyone,

I am writing this post on dev.to because a Gemini-generated script just wiped my entire 2TB NVMe SSD. No data back, all wiped by TRIM.

There was no malice in the script. It was just a bizarre perfect storm of weird conditions and bad path logic that ended in absolute catastrophe. After the initial shock wore off, I spent hours fighting Windows NTFS permissions and dealing with "fabricated confidence" AIs to solve a very specific problem on Windows.

I wanted to protect my main workspace root folders (where Docker containers, databases, or build scripts run) from ever being accidentally deleted or renamed again by any rogue or badly written script running under Administrator privileges.

However, standard fixes (like full recursive Deny locks or changing folder attributes) completely break Docker. Containers inside those folders need Full Control to create, modify, and delete their own temporary files and logs.

AI Logic Failure: Where ChatGPT, Gemini, and Copilot Get It Wrong

When I hit this wall, I did what everyone does—I spent hours testing solutions with ChatGPT, Gemini, and Copilot.

Gemini actually showed me the Parent Override rule, but couldn't understand its own logic. It kept spitting out broken scripts over and over. Copilot completely gave up, telling me to "install an antivirus" or create a virtual ext4 drive and mount my project folders inside it because “NTFS simply cannot do this.”

But I refused to believe that the architect behind NTFS was a complete idiot. I knew there had to be a smart, native way.

Here is exactly why all the AI solutions completely failed:

They don't understand the DC (Delete Child) logic: Gemini knew the override existed but didn't realize that if the Administrator group keeps Delete subfolders and files on the root drive (e.g., D:\), Windows deletes your protected folder "from above." A Deny Delete inside the folder itself is useless if you don't uncheck that single box at the root drive level.
The Inheritance Trap: To fix the lock, ChatGPT and Gemini kept forcing me to click "Disable inheritance" on my workspace folder. This is completely breaks system permissions chains...

The Reality They Missed

I locked onto the idea that Windows protects its own system folders incredibly well. Trying to delete anything inside Windows itself or its related system drives is an absolute nightmare. The native armor was clearly there, so I started a massive chain of experiments on dummy folders (1\2\3\4\5\6\7\8) filled with test files. I hit a ton of dumb, frustrating situations along the way.

Eventually, I found a working method for an ordinary user, and then extrapolated it to block Administrator and SYSTEM privileges.

And you know what? The final fix is just stupidly, mind-blowingly simple. Six hours of writing scripts, manually switching toggles, and deleting test files resulted in a damn 30 second solution that anyone can - and honestly, should do to protect their folders with precious Data. Yes it could be questioned on system drive ( i did not tested it ), but for Data drive it works well enough, at least for me.

By surgically turning off just one specific permission on the root drive and using a precise, non-propagating (NP)(DE) lock, we solve the problem instantly. No disabling inheritance. No file crawling. No virtual ext4 disks. Just pure, native NTFS logic working exactly as it was designed to.

P.S. Sorry for the wall of text, but I just had to explain the pain! =)

The Universal Fix

Step 1: Fix the root drive override (The missing link)

Right-click your main Hard Drive letter (e.g., D:) ➔ Properties ➔ Security ➔ Advanced.
Select the Administrators group (or System or any other) and click Edit.
Clear/Uncheck ONLY one specific permission: Delete subfolders and files (Delete Child / DC).
Save and let Windows apply it. This safely disables the parent override rule without affecting normal file operations inside.

(Note: This safely disables the parent override rule on the drive's root level. It will NOT affect normal file/folder deletion inside your subfolders, as they rely on their own inherited DELETE permissions which are still intact).

Step 2: Create a Right-Click context menu for instant folder locking

Create a .reg file with the code below to add "Folder Protection" menu. It applies a precise (NP)(DE) lock — meaning it blocks deletion of only that specific folder entry, without cascading down into your files and breaking Docker.

Windows Registry Editor Version 5.00

; Create main "Folder Protection" menu entry
[HKEY_CLASSES_ROOT\Directory\shell\FolderProtection]
"MUIVerb"="Folder Protection"
"SubCommands"=""
"HasLUAShield"=""

; Subcommand: Lock
[HKEY_CLASSES_ROOT\Directory\shell\FolderProtection\shell\01Lock]
"MUIVerb"="Lock Deletion"

[HKEY_CLASSES_ROOT\Directory\shell\FolderProtection\shell\01Lock\command]
@="cmd.exe /c icacls \"%1\" /deny *S-1-5-32-544:(NP)(DE)"

; Subcommand: Unlock
[HKEY_CLASSES_ROOT\Directory\shell\FolderProtection\shell\02Unlock]
"MUIVerb"="Unlock Deletion"

[HKEY_CLASSES_ROOT\Directory\shell\FolderProtection\shell\02Unlock\command]
@="cmd.exe /c icacls \"%1\" /remove:deny *S-1-5-32-544"

Pros:

No "Wave" Effect: It updates exactly one single folder entry instantly. It doesn't crawl through millions of files.
100% Docker Friendly: Your programs and containers retain full permissions inside the folder. They can create, edit, and wipe internal files freely.
Any accidental rmdir or renaming script targeting your main workspace folder will hit an immediate Access Denied wall.
Administrator cannot delete or rename this folder without unlocking it first through the context menu.

Cons / Trade-offs:

Manual Unlock Required: You cannot easily delete or rename these folders anymore (even as an Administrator). This is by design, but you have to use the context menu to unlock them first.
No Nested Multi-Unlock: If you decide to lock folders at deeper inner levels (which is great for Docker isolation), you will have to unlock them manually one by one from the bottom up if you ever want to delete the whole tree. Or propagate rule through all tree to get deletion override back.

Little test:

PS Y:\temp> rmdir Protected
rmdir : Cannot remove item Y:\temp\Protected: Access to the path 'Y:\temp\Protected' is denied.
At line:1 char:1
+ rmdir Protected
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (Y:\temp\Protected:DirectoryInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand

PS Y:\temp> ni Protected\test.txt

    Directory: Y:\temp\Protected

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         5/25/2026   7:26 PM              0 test.txt

PS Y:\temp> del Protected\test.txt
PS Y:\temp> dir Protected

    Directory: Y:\temp\Protected

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         5/25/2026   7:25 PM             14 JustText.txt

PS Y:\temp> mkdir Protected\NewFolder

    Directory: Y:\temp\Protected

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         5/25/2026   7:27 PM                NewFolder

PS Y:\temp>

Disclaimer: Just to be clear—I am a 3D/CGI Artist, not a full-time DevOps engineer or Windows sysadmin. I built this purely to solve a painful personal problem and save my own projects. So please, go easy on me with the technical tomatoes!

Feel free to connect or ask questions here or on my LinkedIn.

DEV Community: Seneelya