I know this is a little bit of an old thread, but we were seeing this problem and it turned out to be clock drift between the cluster and the domain controller. Still haven't figured out what's causing the time to randomly drift though.
Thanks for the quick and very helpful reply. I read the article and have only displayed the current settings so far. I noticed SMB1,2, 3 and 3.1 are enabled on the NetApp. Our two DCs show SMB 3.1 as the protocol they are using (in addition to SMB1 being enabled on them too), so I am wondering if the error that was generated when I disabled SMB1 on the two DCs essentially would have been informative only and not indicative of a complete break in connection with the DCs as it first appeared? Would the NetApp not have reverted to one of its other enabled SMB protocol versions to sustain its connection to the DCs? Would it not have "discovered" it could connect via SMB 3.1 and resumed normal operation with the DCs? If so, could I simply disable SMB1 on those DCs as before and simply ignore the alert from the NetApp?
So, following the directions in the article, once I enable SMB2 on the NetApp, it will use SMB2 to communicate with the two DCs, right? Does enabling SMB2 on the NetApp also result in SMB1 being disabled as a protocol to use with DCs, or does it have to be explicitly disabled?
Last question, given the concern with this latest ransomware and SMB1, should SMB1 as it pertains to the client connections, also be disabled on the NetApp, and if so, how?
It looks like the questions have been answered already. I just wanted to make you aware that there is a bit of additional info on ONTAP and SMB 1.0 that can be had at the below link as long as you have a NetApp support site login.