I’ve been using an Hitachi NAS 3080 (HNAS) for some time.
It was upgraded lately to the last microcode version. Usually one must make these updates, or bad things can start to happen. And we don’t like bad things, do we?
At the same time I was migrating some data from another NAS repository to this HNAS.
For reasons beyond this article, I was forced to use command line tools, so I mounted both stores, old and new, on the same Windows 2003 server, in order to copy the contents of the old one into the yet prepared one in the HNAS.
The old one had been managed for long time from this very same Windows 2003 server, and I’ve already successfully migrated data from the old NAS to the HNAS mounting both CIFS stores as local units on it.
For the last migrations I used windows command-line tools like xcopy, cacls and subinacl, as I needed to maintain NTFS permissions.
NTFS permissions are kind of a perilous animal. They seem powerful, plenty of glorious energy; the seem able to allow and deny almost anything a mortal can imagine. But its dark magic require hours and hours of investigation, knowledge, experimentation… They’re full of dark places, tricky tidbits. They can provide you with endlessly hours of frustration navigating through exceptions, bad documented, repeated or unsupported patches, and of course, the microsoft knowledge base.
I hope I won’t find these critical problems with recent versions of Windows, but all the pre-Windows 2k8 zoo is full of these sort of nightmares that make the life of an administrator almost impossible.
One could think that Microsoft is against the administration of its own software. In fact, I’m almost sure of this.
No Unix administrator can even imagine this nightmare to be possible: so, a chmod depends on filesystem versions? a chown can fail? sometimes? what??? U’r kidding. Really. No way.
Anyway, I thought I could tame the beast at least for this last task, but unknown dangers were waiting for me.
As I started applying my well-known scripts, I ended up with NTFS permissions that weren’t exactly the ones that I was waiting for.
The problem was that I wanted my files to inherit their ACEs from the corresponding parents, as is usual btw.
Nonetheless, they end always with explicit ACEs, and without the “Inherit from parent” bit activated. Scary.
In fact, it was not a problem of the commands as I first thought: I was able to isolate the step that was messing the ACLs: changing the owner of a folder changed also the heritage of the ACLs of that object, no matter if the change was applied via a command-line tool or via the GUI.
Now, as nothing had changed from my last successful attempts except for the microcode upgrade of the HNAS 3080, the destination of my attempts, it seems that something has changed there that makes the binomial Windows 2003 + HNAS behave this way.
I’m not very sure how is this possible: isn’t Windows the one to tell the CIFS server the permissions it wants?, and if so, how can they get messed up this way by the remote server?
HNAS’s use a proprietary format to store permissions which allow Hitachi (in fact it’s a BlueArc’s product, bought by Hitachi) to store both Unix and NTFS permissions at the same time for every object stored in its HNAS products. Anyway something is challenging my little knowledge here…
Data was finally migrated using a combination of
xcopy robocopy parameters that wrote everything correctly:
robocopy “origin” “destination” /COPY:DATSO /E /B /R:1 /NP /LOG+:robocopy.log
- /COPY:copyflag[s] : What to COPY (default is /COPY:DAT). copyflags : D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info.
The most relevant flags for this problem were “S” and “O“.
- /E : Copy Subfolders, including Empty Subfolders.
- /B (backup mode) will allow Robocopy to override file and folder permission settings (ACLs); This is useful when File/Folder permissions or Share permissions on either the source or the destination are preventing the copy.
- /R:1 : limiting the number of retries (1 in this case) will speed up copying by skipping any in-use files. Robocopy cannot copy files if they’re in use, but retrying many times is not a good solution.
- /NP : No Progress – don’t display % copied. I did this ’cause i append the progress to a log file with /LOG+. This is always a good idea.
Yeap, this story ends here :(
Many questions remain opened…
unless someone out there can provide me some bright hint to explain them!