Root cannot change file permission or ownership

If I understand you correctly, you want to change the owner of all files inside some directory (or the root) that are owned by user #500 to be owned by another user, without modifying files owned by any other user. You're in that situation because you've copied a whole directory tree from another machine, where files inside that tree were owned by many different users, but you're only interested in updating those that were owned by "your" user at the moment, and not any of the files that are owned by user #501 or any other.

GNU chown supports an option --from=500 that you can use in combination with the -R recursive option to do this:

chown -R --from=500 yourusername /path/here

This will be the fastest option if you have GNU chown, which on CentOS you should.

Alternatively can use find on any system:

find /path/here -user 500 -exec chown yourusername '{}' '+'

find will look at every file and directory recursively inside /path/here, matching all of those owned by user #500. With all of those files, it will execute chown yourusername file1 file2... as many times as required. After the command finishes, all files that were owned by user #500 will be owned by yourusername. You'll need to run that command as root to be able to change the file owners.

You can check for any stragglers by running the same find command without a command to run:

find /path/here -user 500

It should list no files at this point.

An important caveat: if any of the files owned by user #500 are symlinks, chown will by default change the owner of the file the symlink points at, not the link itself. If you don't trust the files you're examining, this is a security hole. Use chown -h in that case.

Yes, chown is the purview of the kernel, but remember that the NetApp is beyond the kernel’s arm reach.  For local filesystems, the kernel translates user I/O requests into local hardware I/O operations (on the storage device).  For remote (e.g., NFS) filesystems, the kernel translates user I/O requests into network communications, asking / telling the server to do what the user wants.

There is no guarantee that the server will do as requested.  For example, NetApp servers can be configured to support Unix-style permissions and Windows-style permissions simultaneously.  Unix/Linux clients will see the Unix-style permissions (user, group, mode, and maybe ACL).  Windows clients will see the Windows-style permissions (user but not group, attributes, ACL, and maybe extended attributes).  The NetApp internally stores a combination of the file properties, and enforces access based on some murky, proprietary algorithm, so a Unix operation might be refused because of a Windows-style permission restriction that the Unix client can’t see.

TL;DR
The NetApp server enforces permissions.  Therefore, the NFS driver for NetApp might be written not to do any permission checks, but to send all user requests to the server.  And so the decision to allow the chown to execute is probably being done 100% at the NetApp.

I don’t know why that would happen.  It might be a bug.  That would surprise me a little, since NetApp has been around for 25 years; I would expect a bug that big to be reported and fixed by now.  It might be a configuration setting on the NetApp.  That doesn’t really make sense, but maybe the administrator of the server doesn’t quite understand what he’s doing (or perhaps there is some obscure policy reason why it would be configured this way).