There is no mechanism I can think of in ONTAP that would move folders or files. It sounds like a host is doing this. ONTAP (cDOT) can move volumes (vol move) or aggregates (aggregate relocate), and can even copy files and folders with ndmpcopy at the cli, but not moves of files. I would look at all hosts and enable auditing to try to see what is moving the directory structures around.
This has to be host based. As scottgelb said, OnTap cannot move sub-directories or files from volume to volume without a backup engine. You can't even create or delete files \ folders from CLI of OnTap. Have you considered setting up Fpolicy?
Assuming this is CIFS you could try seeting options cifs.trace_login on and view messages log file.
What OnTap version are you running? I remember there once was a strange bug with SMB2 that manifested itself in a similar way (files created in a subdirectory disappeared and were later found a few directories further up). But that was with newly created files, not with pre-existing files.
Try disabling SMB2 on the filer to see if that helps. Note that this requires all CIFS clients that are currently connected via SMB2 to reconnect to the filer.
You can also enable CIFS Auditing on the volume to see who/what does the move operation if it's indeed client-initiated
Also you should upgrade to the most recent OnTap version (8.1.4P9 if you're currently at or before 8.1.x, or 8.2.3P5 if you're already on 8.2)
In that case I would strongly suggest you upgrade to 7.3.7P3 as there are a lot of bugs that have been fixed since 7.3.5*, especially with regard to SMB2 support
You should ask your partner/reseller if you need help with upgrading, even though it's rather easy (download new software, install on filer, do takeover/giveback 2 times) there might be dependencies on other software (SnapManager or other 3rd party tools) that you might need to check, and your partner should be able to help you assess these issues.
You can check if smb2 is enabled by entering
NetApp> options cifs.smb2.enable
If it's on, you can disable it with
NetApp> options cifs.smb2.enable off
and re-enable it with
NetApp> options cifs.smb2.enable on
The settings take effect immediately, and if you have Windows clients that were accessing the filer through SMB2 when you disabled it, these clients might need a reconnect with SMB1, which will happen only after some time (depending on the Windows version and settings it can be up to 15 minutes) or a client reboot (usually faster than just waiting). It should not affect existing sessions but since windows continuously tries to disconnect and reconnect, you should be prepared to expect these long timeouts.
Auditing is a bit more involved, you should probably skim over the relevant documentation (File Protocols Access Guide) and over the basic Windows concepts before trying to implement it (misconfiguration can under some circumstances kill your performance or fill up your root volume with tons of logs)
How many users are there (can you walk by and see what they are doing?)? Anyone running a script of some sort that might be doing this? "options cifs.audit" for all cifs auditing but then you also need to change the share properties from a windows host.. don't have the KB offhand but documented nicely on the NetApp mysupport site.
Have you checked who the owner of the folder is that was moved? That is likely to point to the culprit that moved it (folders don't move by themselves). It's possible a user who has NTFS permissions to the data has accidently moved it (drag drop) in windows explorer. What are the NTFS permissions? Have you identified the number of users who have access to the data to try and find out who did it? You could always restore it to it's origonal location and then enable cifs auditing temporarily to identify who is responsible
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.