I’m in the middle of a file server migration and attempting to consolidate two old File Servers onto our FAS2040 running Data OnTap 7.3.6.

Using a tool called Beyond Compare I begin by syncing the content from one file server over to the NetApp. Beyond Compare did the bulk of my sanity checking for me by verifying the contents now on the NetApp matched the contents on the old file server. I then manually began to verify NTFS permissions were copied properly. To my surprise I found that random directories I had synced to the NetApp had inheritance enabled on them while the original directories on the old file server have inheritance disabled.

Here’s the basic structure of our shares:

Old File Server
- Root Folder (Inheritance enabled)
-- [A-Z] Folders (Inheritance enabled)
--- User's Folder (Inheritance disabled)

Real-ish Example:
- User Drives Folder (Inheritance enabled)
-- T Folder (Inheritance enabled)
--- Test User 1 (Inheritance disabled)
--- Test User 2 (Inheritance disabled)
--- Test User 3 (Inheritance disabled)

 

Using Beyond Compare I synced the ‘T’ folder and here is what I ended up with:

File Server (Source):
- User Drives Folder (Inheritance enabled)
-- T Folder (Inheritance enabled)
--- Test User 1 (Inheritance disabled)
--- Test User 2 (Inheritance disabled)
--- Test User 3 (Inheritance disabled)
--- Test User 4 (Inheritance disabled)

NetApp (Destination): 
- User Drives Folder (Inheritance enabled)
-- T Folder (Inheritance enabled)
--- Test User 1 (Inheritance disabled)
--- Test User 2 (Inheritance enabled)
--- Test User 3 (Inheritance enabled)
--- Test User 4 (Inheritance disabled)

 

At first I thought this was a bug with Beyond Compare so I grabbed another file copying utility and tried syncing the ‘T’ folder again. Same results.

I checked the NetApp’s support site and came across Bug 8209 which is titled “ACL Inheritance for New Directories in Error”. According to the bug text (which is very brief) “Prior to OnTap 6.1.1, new directories sometimes incorrectly inherited their parent directories permissions.”

This bug has been resolved in the following versions of Data OnTap:

• Data ONTAP 6.1.1 (First Fixed)
• Data ONTAP 6.1.3R2 (GA)
• Data ONTAP 6.4.5 (GA)
• Data ONTAP 6.5.7 (GA)
• Data ONTAP 7.0.7 (GD)
• Data ONTAP 7.1.3 (GD)
• Data ONTAP 7.2.7 (GD)
• Data ONTAP 7.3.3 (GD)
• Data ONTAP 7.3.7 (GA)
• Data ONTAP 8.0.3 (GA)
• Data ONTAP 8.1 (GA)
• Data ONTAP 8.1.1RC1 (RC)

So if you’re not running one of those versions you’re probably going to need to upgrade OR manually check every folder you migrate/create by hand to verify inheritance is disabled.

 

Update – August 21st, 2012

So I’ve finally just upgraded our NetApp to Data OnTap 7.3.7 and this problem is still occurring for me. It seems less frequent now and so far it’s only been on empty directories but not all empty directories.

Update – August 22nd, 2012

Problem occurs when using either Beyond Compare and RichCopy 4.0.217 to try and migrate the files.

I did some experimenting and it looks like the problem is some kind of corruption on the source directory itself. Using Beyond Compare I tried copying one of the problem directories to brand new post Data OnTap 7.3.7 upgrade volume on our FAS2020 and inheritance was enabled. Same directory to our FAS2040 on a pre Data OnTap 7.3.7 upgrade volume resulted in inheritance still being enabled. I then tried copying the problem directory to a share created on a regular Windows 2003 Standard server and inheritance was once again enabled.

On the source file server I re-applied the permissions on one of the problem directories (Right Click directory, Properties, Security, Advanced, Check “Replace permission entries on all child objects with entries shown here that apply to child objects”, Apply, Ok) and then tried copying it again with Beyond Compare. No more inheritance problems for that directory.

It looks like at this point we may just have some corrupt/damaged NTFS permissions on some of our directories.

So what am I going to do about it? I managed to cobble together a PowerShell script from a few sources that can check for inheritance on directories and spit out a list. I ran it against the source file server and it didn’t find any problems so I can’t fix the problem pre-migration. That means you’ll have to run this script post migration on your destination and manually fix inheritance for the directories the script finds. I’m sure PowerShell could do it for you manually to but I haven’t gotten there yet.

Here is the script:

# Change Z:\ to the directory you want to scan

Get-ChildItem z:\ | ? {$_.PSIsContainer} | ? {
	Get-Acl $_.FullName | % {
		$_.GetAccessRules($true, $true, 'System.Security.Principal.NTAccount') |
		? {-not !$_.IsInherited}
	}
}

You’ll want to change ‘Z:\’ after ‘Get-ChildItem’ to the path of what you want to scan. I’m using map drives to keep things simple.

Original code source: http://www.vistax64.com/powershell/269430-finding-folders-where-acl-inheritance-off.html#post1227572