#Modify root volume security style

1 messages · Page 1 of 1 (latest)

long brook
#

Can we change the security style of root volume from ntfs to nfs without impacting access to the data volumes?

dry marsh
#

that depends. in general, no. how are you accessing the data volumes ? CIFS? NFS?

long brook
#

@dry marsh Volumes are accessed as NFS. root volume is NTFS.

#

Volumes are of UNIX style

dry marsh
#

in this case I think it should be fine to switch it to UNIX style, as everything will be UNIX/NFS then

long brook
#

Thank you! Will try this

timber nova
#

Root volume?

#

Why?

#

Don't ever modify that because ONTAP needs to be able to use that for functionality. I believe it won't let you change it by default and is UNIX already.

dry marsh
#

I guess he is talking about the SVM root, since you can't change the security style of the node root volume anyway

long brook
#

@timber nova I want to modify the security style of the SVM root volume from NTFS to NFS

long brook
#

I have to do this on a customer environment with production volumes

#

I am sure no amount of tests can cover all the scenarios. And when it comes to access and permissions, a lot of things can go for a toss

#

Any idea how can I approach this?

timber nova
long brook
#

yes, I did see a few articles including this. But nowhere it talks about any disruption.

#

If any I mean

#

So I am skeptical

#

In my case, I am modifying the style for a root volume who's svm has around 30 production volumes with full data

undone talon
#

When a data volume is created, it inherits the root volume security style. If you change the root volume security style it will not impact existing data volumes. You definitely should check your export policy attached to the root volume and ensure it will not restrict your NFS clients from accessing the root of your namespace. You can also test your scenarios by creating a test SVM.

dense warren
#

but it may impact access to the mounted volumes (if name-mapping is not configured/setup)

long brook
#

One of my colleagues has tested this scenario. I am not sure to what extent it has been tested. I will do my own testing and find out the impact to mounted volumes

trim mica
#

Same question here but have to move to NFS/UNIX from CIFS/NTFS on both root and datavolumes. Has anyone effective results on whats the impact to change it and is it possible or do I have to create a new SVM with NFS/UNIX security style and migratie data to new volumes. Also the client servers change from windows to linux servers.
If I ask AI:
changing style is not a bestpractice because only new files are affected. And must be able to read not change data. Or have to reapply permission on a lot of TB. Recommended is to create new SVM with new volumes and migratie data.
Scenario Create New SVM?
Root volume is NTFS ✅ Yes (easiest)
Want clean separation of Windows/Linux ✅ Yes
Comfortable changing volume-by-volume ❌ Not required (but be very careful)

dry marsh
#

when changing the security style of the volume, all permissions on files/directories are effectively lost and need to be re-configured

#

you can test how long it takes to re-apply them by using a FlexClone

trim mica
#

Thnx for the idea but Flexclone will be in the Same SVM then I have to test is would be difficult. Maybe its better to snapmirror the volume to a new NFS SVM and change the secstyle on the volume so I can also do test from a linux server?

dry marsh
#

For testing how long it takes it wouldn't matter much in which SVM you do that, it could well be the same SVM.

Then again, FlexClone across SVMs is a thing, that's what the -parent-vserver flag is for

#

Of course you can use SnapMirror but that takes a long time and requires twice the capacity

#

so your downtime will be much bigger

trim mica
#

It's possible because the application can also seed or switch to shares and 90% is readonly data.

dry marsh
#

so basically, make a clone (same SVM or different SVM, doesn't matter), fix permissions in the clone, have users test access in the clone. delete and re-create the clone until permissions are correct. then, when you do the cutover, disable client access, make a last snapshot, change volume security style, fix permissions (from one client that you're giving access), then re-enable client access and test.

#

how long that takes is basically determined by the time it takes to change/fix the security/permissions, everything else is <5min

trim mica
#

Root mounting the clone on a CIFS SVM would be an issue I guess for the volume to do the security / permission change.. but there it is I am not a linux guy...or can it be done if I just set NFS enabled on the SVM.