I did think that NetApp ONTAP created Qtrees would be undeletable by a NAS client (like SMB or NFS client) but no. If the client has sufficient permission, they can delete Qtrees (also move them into another folder, which in effect deletes the Qtree reference and the Qtree just becomes a folder.)
But, there is a way that an ONTAP administrator can create a folder in a share, that is undeletable (and unmoveable) by a NAS client. The answer is mounting another volume into the namespace.
Here is my example.
1) We create a volume (for CIFS, you can ignore the warning about export-policy "default" has no rules in it, not sure why we are still seeing that in ONTAP 9.14.1!):
cluster1::> volume create -vserver NAS_001_TEST -security-style ntfs -junction-path "/TESTVOL001" -aggregate cluster1_01_SSD_1 -volume TESTVOL001
Warning: The export-policy "default" has no rules in it. The volume will therefore be inaccessible over NFS and CIFS protocol.
Do you want to continue? {y|n}: y
2) Create another volume and mount it inside the previous volume:
cluster1::> volume create -vserver NAS_001_TEST -security-style ntfs -junction-path "/TESTVOL001/TESTVOL002" -aggregate cluster1_01_SSD_1 -volume TESTVOL002
Warning: The export-policy "default" has no rules in it. The volume will therefore be inaccessible over NFS and CIFS protocol.
Do you want to continue? {y|n}: y
3) Create a qtree in the original volume:
cluster1::> qtree create -vserver NAS_001_TEST -volume TESTVOL001 -qtree TESTQT001
And accessing the volume over a CIFS share, we see our qtree and volume mounted inside a volume:
Can't read from the source file or disk. |
Optimally. NTFS (or NFS) security permission would be configured correctly to prevent deleting (or moving) folders as required. But if you want to guarantee against folder deletion (or movement) by even a God level NAS user, then mounting volumes inside volumes is a solution!
I remember, back in the 7-mode days, that a NAS client was the only possible way to delete a qtree :) (apart from deleting the entire volume)
ReplyDelete