SMSQL + FlexClone + StorACL

[c_morrall]

I'm facing a bit of an issue with the restore of SnapManager for SQL backups, and one of the venues of investigation is this:

We're using SM SQL 5.2 and SnapDrive 6.4 in a Windows Server 2008 Failover cluster with at the moment two instances. Backups run reasonably well, but we're getting errors during certain restore scenarios. Not boring you with details and logs, I just have a simple question.

We also use StorACL to restrict access to volumes only for set application administrators, server operators etc. From what I've learned, once StorACL is activated, all volumes that are created must be granted an access list or noone will be able to access them. So, when using SnapManager for SQL, which will use SnapDrive to create clones, which will in turn use FlexClone which we have licensed, will the cloned volume inherit the access list from the original volume? If not, the clone would not be able to be used by SnapDrive, sort of breaking the whole solution.

Logs point vaguely in this direction, looking for insights on this.

[abhisek]

Hi ,

StorACL provides RBAC from the windows host machine.The cloned volumes will not inherit the ACL from the proginal volume.

You can provide me the restore logs during the particular failure scenarios with the description of those.

Regards,

Abhishek  

[c_morrall]

Curious. I tried a small experiement outside the SMSQL box, on a plain Windows server with SnapDrive connected to a LUN on a filer with StorACL enabled. The original LUN is on lets say /vol/vol_orig/qt/lun. I created a few snapshots from within SnapDrive, and then mounted "Connect disk" on one of these snapshots. This in turn creates /vol/sdw_cl_vol_orig/qt/lun and connects this lun. This volume is obviously created by SnapDrive as I assume FlexClone.

This all works fine, or not fine depending on how you see it. I can mount the LUN, manipulate it in SnapDrive etc. This should not be possible of the above statement is correct, cloned volume do not inherit ACLs from the orginal volume. The /vol/sdw_cl_vol_orig volume is not visible at all if I check permissions in StorACL.exe, and since StoraACL is enabled, all volumes must have an access list explicitly set correct?

[magnus_nyvall]

Hi!

I also have a bit of storacl problem.

We are running a sharepoint system on three MS Clusters + one verification host.

We have a service account for each cluster and one for the verification host.

We have created specifik aggregate for all sharepoint volumes and then added storacl access like this for all the service accounts:

STORACL>user add –rsn System1:/vol/aggr_sharepoint -rtype aggregate –un mydomain\usr1 –RN SDAdmin

This workes fine for everything except database verification.

We get a user are not allowed SD.Config.Read when the verification host wants to create the clone.

Ofc if I delete the storacl accesslist it all works so it seems to only be a storacl problem.

What i do notice is that it says ipnumber:/vol/xxxxx and not hostname:/vol/xxxxx in the log.

And a user list in STORACL lists the filer hostname. Could it be that it stupidly compares ipnumber to hostname which is different and thus gives no access?

Regards Magnus

[c_morrall]

@magnus

Have you assigned any rights to the service accounts to the entire filer? I noticed this was necessary to be able to mount LUNs, since this writes igroup information on the filer level, this configuration information isn't stored in the volume or aggregate.

user add -rsn  your_netapp_filer -rtype filer

etc, with permissions as needed, outlined in the StorACL documentation.