Also, as a friendly reminder if you are not covered by the regular support entitlements it's ok to be asking here, but if you can upgrade your ONTAP version to 9 would be the best, as 8.2 and 8.3 are in self-service support since this year:
There are currently 6 other volumes and shares in the same SVM. The newest volume created and the share associated with it is the one where we are receiving an error :"Windows cannot access \\sharename\volumename"
when trying to access it via Windows explorer.
As previously said, the security style of this newly created share is NTFS, the same as on the SVM root volume.
Surprizingly, when we create the same share under one of the existing volumes, we can access it without problem.
Check the export policy on the volume. Back in the day, export policies were a thing on CIFS vols. It went optional&disabled by default at 8.2, but any pre-existing SVMs would still have enforcement enabled.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
After many days of troubleshooting with NetApp, the ticket was escalated to a Senior level where it finally found solution: the intra-cluster replication had stopped
It appeared that the problem was caused by the fact that SnapMirror inside the same cluster (intra-cluster replication) had not run since the month of May 2019. Therefore, for the time being, every time we will create a new Volume in this SVM, we will have to manually run SnapMirror command in order for the Root volume to become aware of the new volume since SnapMirror did not run update automatically. The feature is called: Load Sharing Mirror.
In the course of troubleshooting, we ran this command manually:
Thank you for sharing this information. Sometimes, it is impossible to point where the problem could be even if you apply your rational logic. This is really a great knowledge sharing, I don't think I could have thought of this issue.
It makes sense now, SVM root vol load sharing mirror is not automatic, b'cos it does not exists in my current or previous enviorments. So, someone must have set it up following the NetApp best practices. It is still a best practice to create Load Sharing Mirror for SVM root vol.
Every SVM has a root volume that serves as the entry point to the namespace provided by that SVM. In the unlikely event that the root volume of the SVM is unavailable, NAS clients cannot access the namespace hierarchy and therefore cannot access data in the namespace. For this reason, it is a NetApp best practice to create a load-sharing mirror for the root volume on each node of the cluster so that the namespace directory information remains available in the event of a node outage or failover.
Data ONTAP directs all read requests to the load-sharing mirror destination volumes. The set of loadsharing mirrors you create for the SVM root volume should therefore include a load-sharing mirror on the same node where the source volume resides. Looks like in your case, Ontap directed the read requests to LS Mirror on the Node hosting the volumes, and b'cos it was not updated due to Intra-cluster issue, share wasn't accessible, once it was updated it worked!