Caught this after upgrading from 8.3.2P2 Cluster-Mode to 8.3.2P12 Cluster-Mode. We created a new CIFS share and found we could not apply NTFS ACL permissions to the share because it was missing the security tab.
Old shares looked and operated fine.
It turned out the culprit was quiesced LS mirrors. Here’s how to fix:
From here we can confirm that our LS mirrors are in a quiesced state. As per NetApp doc “FA266”:
To a cluster, a volume is a folder. When you create and mount a volume to /, it appears as a folder to the cluster and clients.
A read or write request comes through that path into the N-blade of a node, the N-blade first determines if there are any LS mirrors of the volume that it needs to access. If there are no LS mirrors of that volume, the read request will be routed to the R/W volume. If there are LS mirrors of the volume, preference is given to an LS mirror on the same node as the N-blade that fielded the request. If there is no LS mirror on that node, an up-to-date LS mirror from another node is chosen. This is why the newly created volumes are invisible, since before the LS mirror update, all the requests go to LS Mirror Destination volume, which is Read-Only.
Additionally if we browse the admin share c$, we do not see our new share.
Because there is a LS mirror set in place that was quiesced, meta data for the new share was not propagated to the root vol. Once the mirror set is resumed and updated, the new share replicates the meta data and access is restored.
After resuming the mirror, you can either wait for it to update and sync on its set schedule, or you can update the LS set manually by using “snapmirror update-ls-set”.
We can confirm that the LS mirror set is in sync now because security tab appears on the new share.
And it now appears when we browse the admin share.
One last thing to confirm is that the LS set is being updated on a schedule.
snapmirror show -fields schedule