problem with OpenVMS as NFS client

[dschwarz]

We are runing a two-node cluster with separate system disks
but shared system files like sysuaf, rightslist, netproxy,...
and shared application disks.

Node-A:

$ tcpip sho ver

  HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 3
  on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.3

Node-B:

$ tcpip sho ver

  HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 3
  on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.3

When I log into Node-A using a fully privileged account and try to
mount a NFS share using a DCL procedure on a shared disk,
it works.

When I log into Node-B using the same fully privileged account and try to
mount the same NFS share using the same DCL procedure on a shared disk,
I get

%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000]
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

I checked the NFS server's configuration, both cluster nodes are
registered.

I checked TCPIP proxies - same on both nodes.
I checked the privileges of SYS$SYSTEM:TCPIP$UCP.EXE - same on both nodes

Any idea ?

Thanks

[Volker Halle]

Use REPLY/ENABLE and watch for OPCOM-messages from NFS. Also consider, that the NOPRIV message may be coming from the NFS server. Check that the UID/GID from the IP address of the 2nd node allow appropriate access to the NFS export on the NFS server. Check the NFS log on the NFS server.

Volker.

[dschwarz · Accepted solution]

Problem solved.

Node B tried to mount the NFS share using the IP address of the cluster impersonator.

This address was not known to the NFS server.

After adding this address to the NFS server, everything worked fine.

I used tcptrace to find out the difference between the two nodes.

Volker:

We have no OPCOM messages about NFS neither in case of success nor in case of failure

Thanks.

[Hoff]

Usual best resource for troubleshooting errors with the OpenVMS TCP/IP Services NFS client is the NFS server log.

Empirically, "NOPRIV" is a catch-all error within the  OpenVMS TCP/IP Services NFS client.  I've seen NOPRIV reported secondary to the server not offering NFSv2 services, for instance. 

It's rare to encounter privilege-related audits from within TCP/IP Services.  The code seems to obey no rules and no norms but its own, tends to make its own security checks, and does not use the system routines (which do generate audits).  (Due to these local routines, ssh sessions were once able to entirely bypass the SET LOGIN limit, for instance.)

The OpenVMS TCP/IP Services NFS client doesn't usually generate much in the way of OPCOM messages, and it's not all that great at logging.

VSI is reportedly replacing TCP/IP Services, FWIW.

FWIW and mentioned here on the off chance that this is not the case, I'd expect and assume that these NFS sessions are between clusters, as there's not a need to use NFS to access storage within an OpenVMS cluster.  Serving disk via SCS/MSCP and tape via SCS/TMSCP is almost always preferable to using NFS within a cluster.