NTFS Blind Spot: Docker Bind Mount Protection on Windows (Container-Friendly)

General
,
1

Hi everyone,

I want to share a native Windows solution for protecting Docker bind mount folders from accidental recursive deletion or move disasters.

I am not a DevOps engineer, I’m a CGI / 3D artist. A broken AI-generated script inside one of my containers had a path logic failure. Instead of moving temporary files, it recursively moved and renamed directories from each parent into itself through a bind mount. The workspace structure collapsed, Windows TRIM kicked in, and 1.5TB of data was lost. (only some files less than 1kb survived ,other are 00 00 zeroed to oblivion).

While researching a fix, and how to prevent it for ever happen again, I noticed that most standard tutorials recommend disabling inheritance or using Deny rules. However, these methods either break container workflows (causing Access Denied errors) or fail to stop a process running with high privileges. And they miss something crucial. Alot of sources says - “it is impossible on Windows”.

I spend hours in testing and trying, and found that: The core issue is a common misunderstanding of NTFS delete semantics. Even if a folder is locked locally, the parent-level override (Delete subfolders and files) still allows the folder entry itself to be wiped “from above”. This description could be find, but I think applied incorrectly for the main task - protect data and keep it structured.

My solution is super simple:

  1. Disable “Delete sub-folders and files” (Delete Child / DC) on your root drive level for Admin SYSTEM etc. This safely removes the parent deletion override and sets the correct behaviour without affecting normal file operations inside sub-folders. (Yes it is intentional and crucial for the result. It could be done anywhere in the tree but result is worse. I did not find any problem with it, all installs and work as usual.)
  2. Apply a precise, non-propagating (NP)(DE) protection rule to your specific project folder. In my case it is folders of first line : “Y:\Name”

The Result:
The root folder entry itself cannot be (accidently, not intentional) deleted or renamed by any automated scripts or Admin privileges. Meanwhile, containers retain normal full access inside the directory. No VHDs, no ext4 virtual drives, pure native Windows ACLs.

Since English is my second language I use help to make my text readable.
If You interested in more detail, You could find my step-by-step guide with a right-click registry context menu script, little more story and a 3-minute video demonstration that it works and how it works in my case.

Links are not allowed so you can:
google ( “NTFS Blind Spot” seneelya) to find video or,
search YouTube ( “Folder Protection seneelya” ) or,
read my article on “dev to seneelya”

Hope this helps somebody avoid losing years of work like I did!

3

Can you explain how it is related to Docker besides that you can make a mistake by running a command in a container which you could run anywhere without containers?

4

Yes, the NTFS behaviour itself is not Docker-specific. The same kind of destructive mistake could happen outside containers too — I simply encountered it while building and experimenting with Docker/AI on Windows. Building my AI environment and made a mistake.

Before this happened to me, I honestly did not even think such filesystem corruption was realistically possible from a normal script. I and AI didn’t even use “danger” delete operations , ha.
I am more of a practical user than a professional sysadmin. I did it for the first time . So this entire investigation came directly from painful experience. And there were no working solutions, except — “switch to Linux”.

I focused on Docker because :slight_smile: it happened, really. And only after that I found that it is even possible. But any other way, “folder protection” methods from the internet stop normal Docker workflow.

So the real problem I was trying to solve was:
“How do I protect the top-level workspace folder itself, and its surroundings, without breaking Docker container operations inside it?”

It is simply the path that led me to this solution. It could be used for “Photo protection” or whatever else.

And one more thing — When I started looking around for the solution, everywhere I heard - “it is impossible on windows, NTFS is garbage” and I didn’t agree with it.