Privileges required for the NFS client under OpenVMS 8-4

[Brian Reiter]

Hi folks (again)

System is OpenVMS 8-4 (fully patched)

TCPIP 5-7 ECO 2

Remove NFS server is some kind of AIX host

What privileges are required for the MFS client running under OpenVMS? I can mount the shares quite happily from the system account, but from a user account I get the message

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

There is nothing obvious when I turn on auditing - nothing correlates to that error anyway. Assuming I can work out what privileges are reqired, would it be feasible to install the exes with the required privileges? If so which exes would need installing.

I'd rather not grant too many privilegs to the clients.

regards

Brian Reiter

[Volker Halle]

Brian,

did you check TCPIP SHOW PROXY ?

The NFS protocol works with TCPIP PROXIES, which (for outgoing access from the NFS client) map the OpenVMS Username to a gid/uid combination to be sent to the NFS server. If there are proxies for the SYSTEM account, but not for your user account, this may explain things...

Volker.

[Brian Reiter]

Hmmm,

Curious - the currently working system runs with priv=ALL  so that could explain it. So I'd need to add a proxy between this user and the root account on the remote system. There are no proxies existing at the moment, although the root one could be the default.

We're in the position of trying to get the system running within its own group, removing any access to system level constructs.

[Volker Halle]

Brian,

if there is a local privilege missing, TCPIP tends to explicitly show this missing privilege in the error message:

VAXVMS $ ucx mount dnfs1:/host=axpvms/path="/vms_nfs/nfs"         ! Example from UCX V4.2
%UCX$DNFSMOUNT-E-MOUNTFAIL, error mounting /vms_nfs/nfs
-SYSTEM-F-NOSYSNAM, operation requires SYSNAM privilege
 

So in your case, it looks like this is a privilege problem coming from the remote NFS server. Does the mount from SYSTEM work after SET PROC/PRIV=(NOALL,TMP,NET) ?

If no proxies are defined, the TCPIP client might be sending the default gid/uid pair, which could be -2/-2.

Volker.

[Brian Reiter]

Hi Volker,

The mount fails with privileges set to SYNAM,TMPMBX,NETMBX (using the sysem account). With no clues other than the initial request for SYSNAM as to which are needed. Setting up proxies for -2,-2 or 0,0 didn't help.

cheers

Brian

[Volker Halle]

Brian,

so you're saying that SYSTEM with privs set to only (SYSNAM,TMPMBX,NETMBX) fails to mount that remote NFS share, but SYSTEM with all privs works ? And the same mount command from the 'user' account also fails in the same way ? If so, you could try enabling privs for SYSTEM until it works...

But my gut feeling is, that the SYSTEM-F-NOPRIV error comes from the NFS server. Use TCPDUMP or TCPTRACE to check, whether the failing mount sends/receives any messages from the NFS server.

To determine the 'correct' proxy settings, you need to ask the system mgr of the remote NFS server node, which gid/uid it expects to allow access to the remote directory and files...

Volker.

[Brian Reiter]

Hi Volker.

I was in the middle of doing the TCPTRACE command. From the user account no traffic is seen at all, even though I get the standard error message. From the working system account plenty of traffic is seen.

cheers

Brian

[Volker Halle]

Brian,

then you have to turn on individual privs - one at a time- under SYSTEM, until the mount works (starting with only SYSNAM,TMPMBX,NETMBX).

Volker.

[Brian Reiter]

Hi Volker,

I had already started on that. It looks as though CMKRNL is the magic button in this case. Next question is, is there an easy way around this restriction? 

cheers

Brian

[Volker Halle · Accepted solution]

Brain,

this sounds like a bug - you may want to contact HP. There are newer NFS client images available beyond V5.7 ECO 2 (their ident should be V5.7-ECO2-22011).

Please see http://h30499.www3.hp.com/t5/Networking/NFS-v3-mount-to-directory-tree/m-p/4834519

Does TCPIP MOUNT/SHARE work ?

TCPIP$UCP.EXE should be installed with Privileges = CMKRNL PHY_IO anyway (check with INSTALL LIST/FULL SYS$SYSTEM:TCPIP$UCP). The mount code seems to be implemented in TCPIP$DNFS_MOUNT_SHR.EXE - a shareable library.

Volker.