Informatics

HNAS 3080 microcode update and Ms Windows 2003 NTFS

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

Parameters mean:

  • /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!

Advertisements

3 thoughts on “HNAS 3080 microcode update and Ms Windows 2003 NTFS

  1. Hi Circulosmeos. We’re facing exactly the same problem as you described. Which parameters of xcopy did you used to make the inherit flag retained? Thanks.

    • Hi Celina,
      Ops, checking my doc I noticed that I used robocopy, not xcopy…
      I’ve updated the article in order to show you the info.
      Hope this will be useful to u.
      And pensive to see that Hitachi hasn’t patched this yet!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s