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

Hey everyone,

I want to share a native Windows solution for protecting folders from accidental and(or) recursive deletion or move disasters.

My Short Story

I am not a DevOps engineer; I’m a CGI / 3D artist. A broken AI-generated script recently had a critical path logic failure. Instead of moving temporary files, it began recursively moving and renaming directories from each parent into itself across the entire drive. The workspace structure collapsed, Windows NVMe TRIM kicked in, and 1.5TB of data was lost. Only a few files less than 1KB survived; everything else was 00 00 zeroed to oblivion.

There was no malice in the script. It was just a bizarre perfect storm of weird conditions and bad path logic that ended in an absolute catastrophe. After the initial shock wore off, I spent hours fighting Windows NTFS permissions and dealing with the "fabricated confidence" of AI models 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 script running under Administrator privileges, or by my own accidental mistakes.

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. Standard locks make the folder completely unworkable as a development space.

AI Logic Failure: Where LLM Assistance Hit Its Limits

When I hit this wall, I did what many people do now — I spent hours testing solutions with ChatGPT, Gemini, Copilot, forums, and old Windows permission tutorials.

Interestingly, Gemini actually pointed me toward the Parent Override rule. However, it failed to connect its own logic. It kept generating increasingly complex scripts that simply did not work in practice. Copilot eventually gave up entirely, telling me to "install an antivirus" or create a virtual ext4 drive to mount my project folders inside because “NTFS simply cannot do this.”

Even checking the most popular online community boards and the supposed hubs of tech knowledge yielded the same dead ends. The common recommendations were always variations of:

• Disabling drive inheritance (which completely breaks system permissions chains).
• Applying recursive Deny rules.
• Using third-party locking tools.
• Or simply accepting that “Windows cannot safely handle this natively.”

It became clear that the models were trained on — and confidently reproducing — the exact same loop of shared misinformation and broken permission advice repeated across forums, tutorials, and even some official recommendations. But that answer never felt right to me.

The architects behind NTFS built a robust enterprise-grade file system with extremely deep and deliberate permission semantics. Windows itself protects many critical system folders extremely aggressively. The underlying NTFS logic clearly already existed somewhere — so instead of giving up, I started running a massive chain of manual experiments on dummy folders (1\2\3\4\5\6\7\8) filled with test files, to see how deletion semantics actually behave.

Here is exactly why the standard AI solutions completely failed:

1. The Core Deletion Semantics Deficit: The models consistently failed to truly reason about how Delete subfolders and files (Delete Child / DC) semantics actually behave in practice. Even if you place a local Deny Delete inside your project folder, Windows can still delete the folder entry "from above" if the Administrator group keeps that DC permission enabled at the root drive level (e.g., D:). Trying to apply this override at a parent folder level instead of the actual root remains highly fragile. In certain scenarios, inherited rules can still bypass your local override, leaving the folder vulnerable to deletion.
2. The Inheritance Trap: To implement a lock, ChatGPT and Gemini repeatedly insisted on clicking "Disable inheritance" on the workspace folder. Doing this completely breaks system permission chains, causes severe access issues inside the folder, and creates a highly complicated mess when you inevitably have to manually recreate and fix all the overridden permissions.

After hitting plenty of frustrating edge cases along the way, the final fix turned out to be absurdly simple in retrospect. Six hours of writing scripts, manually switching toggles, and deleting test files resulted in a simple 30-second solution that anyone can—and honestly, should—do to protect their precious data.
While modifying root permissions on a system drive (C:) requires careful consideration and wasn't my use case. In my testing, it works reliably on a dedicated Data drive. But I am certain that it could be extrapolated to the (C:) with some limitations.

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 native NTFS permission logic working exactly as intended.

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)

1. Right-click your main Hard Drive letter (e.g., D:) ➔ Properties ➔ Security ➔ Advanced.
2. Select the Administrators group (or SYSTEM) and click Edit.
3. Clear/Uncheck ONLY one specific permission: Delete subfolders and files (Delete Child / DC).
4. Save and ensure you let Windows propagate and replace all child object permissions across the entire drive. Yes, it might take some time if you have millions of files, but it ensures that the parent override vulnerability is completely closed and cannot be bypassed anywhere in the tree. In practice, this removes the parent-level NTFS deletion override behavior that normally allows high-privilege processes to bypass local folder-level deletion protection.

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 remain intact.

Doing this at the root level is intentional and absolutely critical for the lock to work. Technically, you could apply this change lower in the folder tree, but the actual deletion lock will fail in certain edge cases, making the protection unreliable. Removing this specific override simply disables a background system behavior that you don't need for normal daily tasks anyway. In my testing, it causes zero issues—all software installs, updates, and workflows run exactly as usual.

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

Create a .reg file with the code below to add the "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.
• Hardened Deletion Block: Any accidental rmdir or renaming script targeting your main workspace folder will hit an immediate Access Denied wall.
• Local Administrator Protection: The Administrator account cannot delete or rename this folder without unlocking it first.

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 must unlock them first.
• No Nested Multi-Unlock: If you decide to lock folders at deeper 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 directory tree. Alternatively, you can temporarily re-enable Delete subfolders and files (DC) at the parent level and wait for it to propagate down through all the files.

Demonstration & Live Verification

Here is a raw PowerShell log demonstrating exactly how this NTFS setup behaves in practice. As you can see, the main directory blocks deletion, but creating, writing, and deleting files inside works flawlessly:

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>

P.S. Disclaimer: I am a 3D/CGI Artist, not a full-time DevOps engineer. So please, go easy on me with the technical tomatoes! =)

===================================================

P.P.S. A Historical Hypothesis (Circa 1995)

// Disclaimer: This story is a work of fiction.
// Any resemblance to real-world system architects or annoying managers is purely coincidental.

Maybe it's just a legend. But here is my theory:

Back in 1995, a "boring engineer" designed a strict and perfect security system for FileSystem. One day, a manager ran into his office shouting: "Your rules are too strict! Even I, the Super-Admin, cannot delete a root folder if a User-Admin locked something inside it! Fix this!"

So, the engineer made a grim face, scratched his beard, and added a special, high-priority rule. But he warned the manager: "Look, this is a dangerous hack. It is like a custom back-scratcher over the fence. It is highly specific, and you should never turn it on by default!"

Time passed. A new manager came and asked: "Why doesn't our Admin group have all the permission boxes checked by default? I want absolute power out of the box!"

The engineer tried to explain deep system logic and other boring tech stuff. The manager looked into the window, spring was lovely... : "Meh.... anyway. Just check all the boxes for Admins so it looks cool and mighty. Yep-yep. Check all the boxes and call it safe." Time passed.

Then, John the Intern and Sarah from Marketing came to design the UI window. They saw the technical name — something like HighPriorityOverrideParentalCascade—and said: "Ugh, too boring! Let's name it something simple, like 'Delete sub-folders and files!'." Then they looked at the layout: "Look, this checkbox is sitting all alone. It ruins the design. Let's line it up neatly into two columns with the others."

And just like that, a dangerous override rule ended up enabled by default for the next 30 years.

Today, forums and tutorials still repeat the same advice: "Break inheritance. Use third-party tools. Windows cannot protect folders from local Admins. Switch to Linux."

Well, turns out that NTFS can do it. You just have to take away their back-scratcher. 😉