In our shared application file system instance, where a SAN mount on database server is NFS mounted on 4 application servers, we were installing Olite. Olite requires running root.sh script. But the root.sh always gave permission denied whenever we ran it from the application tier. This was happening because the uid and gid of root did not match on the application server and the database server. Application Server was installed as Solaris 10 where root's gid is 0. DB server was upgraded from Solaris 8 to Solaris 10. In Solaris 8 the root user's gid is 1. After changing the root user's gid to 0, the script ran fine.
NFS does NOT behave the same as a local filesystem, especially for root! NFS is a very non-secure method to share filesystems and unless the NFS server exports the filesystem with a special root option, the root user on the local computer is nobody (literally!). That's why there is a 'nobody' user and it has a user ID of -2. This user has NO special privileges. Th1e reason is fairly obvious. If a server were to blindly export filesystems to any computer on the network (with root=root privileges), then the contents of the filesystem could NEVER be trusted as any machine could trash any file or directory.
So even if you were root on your local box, chown will return EPERM (errno 1) because the NFS filesystem says you are nobody and therefore not the file's owner. /etc/exports on the NFS server can allow root access but one should be very careful to restrict root privileges for the above mentioned reasons.