Bug: NTFS permissions removed on a *parent* folder when a child folder is deleted

[Arthur]

Fixed in the latest CU apparently.

 

More info: www.reddit.com/r/sysadmin/comments/8d6uit/a_situation_in_which_server_2016_will_remove_ntfs/

 

My org has found an issue in Server 2016 and have been working with MS Premiere support with a Sev A, Critical Situation incident for ~2 weeks to figure out what's happening and identify a solution.

 

The Short version: On Server 2016, with a Shared folder that's top level is set to " Read/Execute This folder only" and has a child folder that has inheritance enabled and has any explicitly defined permission, when the Child folder is deleted, the top level " Read/Execute This folder Only" will be REMOVED.

 

When we first ran into this, we thought it to be crazy. Permissions should NEVER flow up.

 

At this point, we have been able to reproduce this issue at-will on

 

1. Server 2016 file server failover cluster with up to March updates
   
2. Same as previous, with April updates
   
3. Server 2016 NON-cluster with March updates.
   

We were NOT able to reproduce on Server 2012R2 or 2008R2.

 

www.theregister.co.uk/2018/11/28/microsoft_windows_10_server_2016_patch

 

The problem was reported back in February, when a user in Microsoft’s TechNet forum came across some decidedly odd behaviour when deleting a sub-folder. Permissions of parent folders appeared to go AWOL when child folders were deleted.

 

Another user on Reddit shared a similar experience. He found that when a parent folder had an explicitly defined permission with a child folder with inheritance enabled as well as explicit permissions, deleting that child folder would remove the Read/Execute permission from the parent.

 

At least it was removing rather than adding anything, but still. It is at best counter-intuitive and at worst a pretty nasty bug.

 

The Redditor went on to document the 40 or so hours spent dealing with Microsoft's support team to be told initially that the behaviour was by design and introduced in Windows Server 2016. Interestingly, it only occurs when folders are deleted (or cut and pasted) using File Explorer. Using the command line makes things behave as one would expect. It also only occurred when using a local path. Deleting using a UNC path was fine.

 

The workaround over the last few months has therefore been to either remove any explicit permissions on the child folder before deletion or stick with UNC paths. Or there is always the command line.

 

KB4467684 purports to deal with the problem in Windows Server 2016, much to the delight of harassed admins.

 

Alas, the original poster in the TechNet forum, Rolf Berger, has reported that his issue "is still not solved", so your mileage may vary. We've contacted Microsoft for more information and will update if anything is forthcoming.

 

https://twitter.com/SwiftOnSecurity/status/1067562129157472257