2011-03-10 06:53 AM
I need to figure out a way to change the file and folder permissions on the OSSV destination. I do not have the ability to change the permissions on the source, as those ojects are owned by another entity. However, I need to assign permissions to a different set of accounts to be able to read the objects at the destination (SnapVault destination).
Since SV destinations are read only, I think I'll need to clone and re-perm somehow. Perhaps, snap clone the objects, use fSecurity to change the permissions, set back to "read only", then Create the share. The end result doesn't need to be able to be updated automatically, so when the data is updated, I could simply destroy the copy/clone and re-create. However, I do need to this to be something that is scripted. Total amount of data is somewhere in the 300gb range. Not huge.
What are your thoughts? I don't have a ton of space, so it would be preferred if can do this without actually duplicating all the data. However, if we need to, I should be able to free it up.
I'm currently running DOT 7.3.3 and plan on updating to 8.x within the next 6 months.
2011-03-14 11:21 AM
I'm thinking I need to do a vol clone create to create a clone of the Snapvault destination. However, even after adding Full Control to the share of the new clone, I'm still unable to make any changes.
Do I need to use something other than vol clone? Perhaps vol copy?
Edit: I did verify file/folder level permissions as "Full"
2011-03-15 06:34 AM
Funny thing is, when I do the following command to create the clone
vol clone create OSSV_RW -b OSSV
The clone is read only. However, If I do the same command to a regular volume, that clone is RW.
It appears that there is a problem creating a RW clone of a snapvault volume.
2011-03-17 06:21 AM
Found the problem. I was mounting the wrong snapshot. Following this link:
the steps work. However, it is CRITICAL to mount the "-base.1 (busy, snapvault)" snapshot. Mounting any others will result in a read-only mount.
Now, my biggest issues are in Netapps poor implementation of SDDL, in not allowing spaces or _ in user/group names. But - then again - who would be giving permissions to a group like "domain admins" anyway?
2012-02-29 03:55 PM
I would like to extend this question and perhaps get a little more clarification from someone that has more experience with Windows OSSV than myself. Basic architecture is using OSSV 3.0.1 on Windows 2008 R2 and snapvaulting to a FAS running DOT 8.02. Getting that baseline and updating works well, no issue. from reading this thread, it would appear simply mounting up the destination volume and adding a CIFS with share level permissions is not going to allow you to have other users actually see the file-level data from the mounted drives that are snapped from the Windows server because of the ACL's it copys from the source are replicated and pure (in additional to read-only). Specifically, I (as an administrator) can somehow see all the data perfectly, (with good reason as I own the share on the NetApp) but our recovery group maps to the share and doesn't see the qtrees created via OSSV. I thought perhaps that was because they were not a member of the local administrators group on the destination like me so I gave them temp access to that local group on the controller, but still no luck. So, I really just need to somehow get them access to the qtrees (and associated ~snapshot dir). Any direction would be helpful, and if something is not clear on what I'm trying to do, please ask. Next step will be to post to NetApp via ticket, but hoping I can save myslef some frustration...