I'm actually wondering how you got any operation in your (probably bash) shell completed on a file with hyphens ( - ) without getting an error.
Try escaping special characters in file names (if you really have to use them) with a backslash or single quotes.
You should review the linux manpage (or whatever other help system your distro uses) as well as check what the filer sees as export/mount rights by using 'exportfs -c .... ' ... see the NetApp manpage for exportfs.
The NFSv4 down-grades the root to nobody. And there seems to be no way, to assign a user accessing a NFS mount via NFSv4 root rights on the filer. Without root rights on the filer, there is no way to change the owner of a file.
So I was wondering, whether that implication is correct.
The automatic downgrading, I would think, is the result of not being able to map who root is, perhaps. Anyway, that would break just about everything. NFSv4 is just hard to implement in mixed environments if one wants to share anything CIFS and NFS since one needs to use the AD controller for kerberos because no unix variants exist that support CIFS... but I digress...
The only other apparent possible error is a bug in the linux (l33n0x) implementation for NFSv4. A quick Google search points to recent situations such as yours.
The root cause was that the idmap daemon didn't run. SInce we use SLES11, even the client needs the nfsd to run. After having that nfsd up and running, also the gss and idmap processes could start. Afterwards the chown did work out even the setting of "o" right ACL to a technical user worked out. So there is no need to work with root anymore.