We have an old support article on “What does MAC authentication failed mean?”: https://cryptomator.freshdesk.com/support/solutions/articles/16000003666
In your case, I assume that the copy process was somehow tampered with. Is there anything special on how you copied these files? The encrypted files were most likely manipulated, maybe even afterwards by an antivirus software. Or maybe even something with OneDrive, even though I haven’t heard a similar report yet. Does this happen without having OneDrive involved?
This is extremely hard to debug and I don’t think that Cryptomator’s debug logs would help that much because the manipulation most likely happened “from the outside” on the already encrypted files. By that, I mean the files in d/XX/YY/ZTNHM...II===.
But you can check out the log file and see if there is a more specific error message. You could also use Sanitizer to get a more detailed analysis. However, none of these methods will actually find the actual cause of the issue. Because when the manipulation on already encrypted data happens, it’s too late.
I remember a curious case when someone used Midnight Commander to copy a vault: https://github.com/cryptomator/cryptomator/issues/456
The copy mechanism “replaced all linux style line endings with windows style line endings which understandably breaks the encrypted files”. But I guess that’s not related to your issue since that would probably break all files.
In the past, authentication failures were detected in the desktop app as well (as you can see on the screenshot of the article I’ve linked). However, with 1.3.0 we made major architectural changes and that’s why the iOS app behaves differently in this case.