You basically just need to use the first export with "-sec=sys", as long as the NetApp can't map the user ID to local information, the files belong to nobody.
You don't really supply much information. You can also just set the sticky bits on the toplevel directories and chown them to nobody from a server that you have exported "root" mount access rights to.
From the exportfs(5) manpage:
Specifies the effective user ID (or name) of all anonymous or root NFS client users that access the file system path. An anonymous NFS client user is an NFS client user that does not provide valid NFS credentials; a root NFS client user is an NFS client user with a user ID of 0. Data ONTAP determines a user's file access permissions by checking the user's effective user ID against the NFS server's /etc/passwd file. By default, the effective user ID of all anonymous and root NFS client users is 65534. To disable root access by anonymous and root NFS client users, set the anon option to 65535. To grant root user access to all anonymous and root NFS client users, set the anon option to 0.
Re: mount.nfs: access denied by server while mounting from Netapp
I can't really tell you much about the Windows NFS implementation. I've never used it. Does "-sec=sys" not work for Windows mounts?
Checking mount problems on filers is basically just a matter of running 'options nfs.mountd.trace on' and/or using 'exportfs -c client_IP /vol/your_vol [rw|root|sys|none] ...
Again, you may have more success using a qtree below the volume level, mounting the volume itself as root from somewhere, then setting the owner to nobody and the sticky bit (chown nobody:nobody qtree_name, chmod +t qtree_name), than trying to hack this via mount options.