Only got this fully resolved yesterday. It appears a change was made at 9.4 P3 that stops RSA and ED25519 keys
from working to the admin SVM. Switching to ECDSA keys resolved the problem.
Message seen in log was:
00000018.0025399a 0f15eef9 Wed Mar 27 2019 12:14:42 +00:00 [auth_sshd:info:29433] userauth_pubkey: key type ssh-ed25519 not in PubkeyAcceptedKeyTypes [preauth]
Hello,
Did you resolve this issue? We have the same issue.
Regards, Andrin
Hello Andrin--No, we have not been able to resolve the issue. We opened a ticket with Microsoft who did a lot of troubleshooting with us, but came to the conclusion that it was an issue with the NetApp. We attempted to open a ticket with NetApp, but were immediately told that the issue was with Microsoft and no troubleshooting was done. I'm currently trying to get NetApp and Microsoft to communicate with each other on this issue, but that is not going well at all. If I make any progress I will gladly update you. I'm hoping you will do the same. Thanks!
My P O I N T exactly.
If I am moving and deferring cutover for a volume that is 100TB's, and it is waiting for a week, I would expect to have multiple TB's of changes. If the process is not using snapmirror or snapshots, how can it update the state of the volume to the latest base image?
I am left to infer that it does not, and ergo the massive data loss our scientists are seeing when using "vol move".
Unless I see something from Engineering, stating otherwise, I am reverting back to SM's.
Hello
I was wondering how the used space for snapshot copies is calculated.
For one of our volumes I got the warning that the snap copy reserve was full. After resizing the snap % reserve I wanted to check how big the snaps are.
When executing snap list for the volume I got following result:
daily.2019-03-24_0010 124KB 0% 0%
daily.2019-03-25_0010 124KB 0% 0%
daily.2019-03-26_0010 148KB 0% 0%
daily.2019-03-27_0010 124KB 0% 0%
daily.2019-03-28_0010 124KB 0% 0%
daily.2019-03-29_0010 124KB 0% 0%
daily.2019-03-30_0010 128KB 0% 0%
daily.2019-03-31_0010 124KB 0% 0%
daily.2019-04-01_0010 128KB 0% 0%
daily.2019-04-02_0010 124KB 0% 0%
snapmirror.9ae9ced5-e0ce-11e7-8a04-00a098ba4130_2159183606.2019-04-02_150500
1.37MB 0% 0%
A df -h gave me following output:
Filesystem total used avail capacity Mounted on
/vol/vol_1/.snapshot
1024GB 763GB 260GB 75% /vol_1/.snapshot
I thought the snap reserve space was used by de snaps, but the sum of the sizes does not correspond to the used size from the df -h command. Can someone explain how the space is calculated?
Best regards
C
I realize this hasn't been asked yet.. what version of ONTAP are you on. vol moves between 7mode and Clusterd ONTOP are (slightly) different.
Also, if you are having data loss, please open a P1 ticket with support.
audit-guarantee does exactly what it says. It ensures that the SMB operation is successfully audited before the ACK is returned to the client. It eliminates the need for the EventID 516/4612 (Audit events lost). If the audit log entry cannot be recorded while audit-guarantee is on, then the CIFS operations either gets delayed or denied. When audit-guarantee is off, then the CIFS operation can be completed without sucessfully creating an entry in the audit log. This is only for evtx/xml auditing.
9.3.2P8
You may want to select a principal to audit before you can chose which things to audit.
You should be seeing zero issues/loss with vol moves, CDOT/ONTAP vol moves are all non-disruptive. I would open a P1 to further investigate at this point.
I just ran into a problem (after upgrading from 9.3P6 to 9.4P6) where I could mount an NFS volume using 4.0, but would get an access denied error when I tried with 4.1. Changing the default export policy from RO any to RO UNIX in the OCSM (which is equivalent to setting it to "sys" in the CLI) makes NFS 4.1 mounts work again. Interestingly, this seems work even if the export policy on the specific volume I'm mounting is any.
I tried to test this in ESXi 6.7 by changing the default export policy back to any and then adding an nfs datastore (as 4.1) and I can't recreate the problem. On an Ubuntu Xenial system, though, reverting the export policy change once again results in access denied errors.
I should note that explicitly setting the sec=sys option to the nfs mount command also solves the issue if your default export policy uses any instead of UNIX.
"Once it is ready to trigger the cutover, it updates, I believe, from the origination snapshot, cuts-over the volume, but does not update files created or modified after the origination snapshot." --> this is not how it works.
Vol moves will sync up the source and destination for cutover. We don't use the original snapshot, because we'd have data loss, like you mentioned.
What could be happening here is that the cutover is slow or that the vol moves aren't completely done. As mentioned, a support case is your best bet to get to the bottom of what's happening here.
Once you've resolved the issue, if you could post back here with what the fix/root cause was, that would be useful. 
Thanks for the direction.
I reinitialized both the nodes and now I can create clusters.
1)
For the first node, I have run 'cluster setup' wizard and completed the steps. I see ports e0d & e0f (connected to node2) have taken IPs automatically in range of 169.254.x.x
Do I need to manually configure IPs on this eod & eof or keep it as it is.
2) For cluster management IP, port e0c should be connected to network switch, correct ?
cluster setup needs to run from both nodes, the first node you "create" the cluster, the second node you "join". the cluster setup wizard auto-creates these 169.x.x.x addresses on both nodes for use in the cluster. So there's no need to manually configure them.
e0d on controller 1 should be connected to e0d on controller 2. and the same for e0f
As far as the other ports you have free, e0a, e0b, e0c, and e0e it really depends on what you want to do with them.
You can use the e0c ports for the Cluster mgmt lif, but it can live just about anywhere, even on e0M if you want. All depends how you want to configure the networking for access on the 2520.
I just tried it with NetApp Release 9.1P10:
::> cifs delete -vserver foobar
In order to delete an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with sufficient privileges to
remove computers from the "foobar" domain.
Enter the user name: test
Enter the password:
Warning: There are one or more shares associated with this CIFS server
Do you really want to delete this CIFS server and all its shares? {y|n}: y
Warning: Unable to delete the Active Directory computer account for this CIFS server.
Do you want to continue with CIFS server deletion anyway? {y|n}: y
Worked like a champ!!
Have you thought of using EMC's emcopy utility? I believe you can use it in Backup mode with your service account and get the data copied over safely. It operates much like Robocopy, but after the initial copy it's much faster to compare and only copy changes files.
This command doesnt work from any nodes in one cluster, but works in the other cluster.
Can Experts please advise what LIF's will be used in this command? or what should I look into?
Thanks!
my question would be, is the automated cutover failing and you are performing a manual cutover? I think others would be interested in the ultimate underlying cause and resolution of this case if you're able to share. Thanks