The reason for this is because NFSv4 clients send symbolic user/group names rather than numeric userid/groupid as it was in NFSv2 and NFSv3 and the filer needs some way to map this symbolic names to numeric IDs. If the information in /etc/passwd and /etc/group information between the filer and the Linux host does not match, the filer will use nobody:nobody for the user/group file ownership.
Please refer to this kb:
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Network_File_System_v4_mounts_show_file_owners_as_root_or_nobody_or_nf...
Another KB: (In your print out this is already set to 'any', so this may be ruled out)
When the root user instigates the touch command to create a file, the file owner, group is set to nfsnobody (Superuser Security Type is preset to 'any'):
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/File_permissions_for_owner%2C_group_reflect_as_nfsnobody_for_ONTAP_9
Cause:
The export policy rule applied to the volume has the superuser set to 'none', which squashes the root user to anonymous user.The anonymous user by default is set to uid 65534, therefore, the files created are owned by uid 65534. UID 65534 is interpreted by some Linux clients such as RedHat as 'nfsnobody'.