Did you have to install the hclnfsd or pcnfsd on the netapp?
You simply need to enable the PCNFSD implementation that is built in to ONTAP. Like so:
filer> options pcnfsd.enable on
You may also want to set the pcnfsd.umask option to a value that makes sense for your environment. The PCNFSD in ONTAP implements version 2 of the protocol, without the print RPC's (filers don't do printing, so they're not applicable to our environment).
We get no HCLNFSD/PCNFSD running on host when we try to connect.
HCLNFSD (formerly BWNFSD) is a functionally similar daemon to PCNFSD, although it is implemented with a different and distinct set of RPCs. It's main reason for existing was that it implemented *working* PC(NFS) style locking semantics before the days when Sun's lockd contained enough stable functionality to do so. It also supported secondary group assignments before PCNFSD, which only introduced secondary GID support when the version 2 daemon shipped. In other words, most, if not all of its reasons for existing have now gone. HCLNFSD is not supported in ONTAP, but that hopefully shouldn't matter.
From: Fred Ab ab@paloma.latticesemi.com
We use Hummingbird's NFS Maestro on NT but have problems with locking issues. [...] If somebody has an idea for me to check and test I'm willing.
The Data ONTAP SecureShare technology integrates PC(NFS) locking mechanisms with those that are native to CIFS. To give you a simple example, if a Windows/CIFS client opens a file with no sharing specified (no FILE_SHARE_READ/FILE_SHARE/WRITE flags), then SecureShare wouldn't allow a Windows/PC(NFS) client to open that same file until it was closed by the Windows/CIFS client. While such behaviour can sometimes be "surprising" to the human user (I know of no other multiprotocol locking implementation in the industry that integrates the paradigms to this level of depth), it does protect data from many potentially disasterous scenarios.
Keith