Karlsson,

I'm not sure of the cause of the error or how to fix it (OK, what are the odds that you've now deleted the email?), but I want to clarify how SV works.

SnapVault indeed only transfers changed blocks from the source system (SV or OSSV - LUN or file), but it isn't a "block level copy" in the way you're thinking of it. On a NAS system, for example, SnapVault rapidly determines the changed files and directories, their changed/new attributes, and then the changed blocks within them (we do this using snapshots, not the traditional file system traversal that is so painful/slow/expensive to run).

Therefore, when you run a SnapVault you are really creating files, writing data, and setting permissions, ACLs, etc. So, it's not technically impossible to get "could not set permissions". Which is why we have an error code to that effect. Of course, that *shouldn't* happen since SV is such a privileged user it shouldn't get a "permission denied" (hence it results in an error code).

Long story short - I would open a support case with NetApp about SnapVault (not Protection Manager) to resolve what's going on.

As for the gray hairs, I recommend dying it all bright blue. That'll distract people from the gray. ;)

Good luck, Sm Onetime Prolific Toaster Poster for Data Protection

-----Original Message----- From: Karlsson Ulf Ibrahim :ULK [mailto:ulk@forsmark.vattenfall.se] Sent: Monday, February 02, 2009 3:47 AM To: toasters@mathworks.com Subject: Strange SnapVault error

Hello everybody!

I have a SnapVault relationsip that's starting to give me gray hairs..

On the primary there's a flexvol with 4 qtrees, being backed up by SnapVault to a corresponding qtrees on the secondary. Three out of four works without problems, but one of the qtrees stopped working 3 days ago.

The error as seen in Operations Manager is : replication destination could not set permissions on a file or directory

This is strange, SnapVault is a block level copy of the primary file system...

Any suggestions?