NFS v3 mount to directory tree

[Mike Fazio]

I'm in the process of setting up a new VMS 8.4 server and ran into an issue with NFS.  I want to be able to take advantage of the NFS v3 client included with TCPIP V5.7-13ECO2 for the larger file size limit but the mount commands that I was using on pre-ECO2 are hanging the process and failing to mount the share.  So far I've been unable to find any explanation for why this is occurring or anyone else that is having this issue.  Has anyone seen this before or have any ideas of what else I can try?

$ tcpip mount dnfs4:[nfs.save]/host="NFS_SERVER"/path="/vol/lvsave"/system/structure=5

%TCPIP$DNFSMOUNT-E-DIRNOTCRE, _DNFS4:[NFS.SAVE] directory file not created
-SYSTEM-F-DEVNOTMOUNT, device is not mounted

OPCOM is also throwing a message:

Message from user SYSTEM on EULER
Client NFS ACP (00000422) - fatal error detected, exiting
Signal arguments:

    00000005
    0000000C
    00000000
    00000070
    0009BD10
    0000001B

sh dev d provides a status of "Mounted dismount" for DNFS4.  

I have checked with our NFS admin and the NFS server isn't even seeing a request to mount.  If I remove the directory tree in the mount command I am able to mount the share at the root of the disk, DNFS4:. The documentation eludes to being able to mount an NFS share to a directory tree. 

[Hoff]

The NFS client is tossing an access violation (ACCVIO) involving what looks to be an uninitialized variable.

Here's the usual mount I've been using (sometimes with /noadf, sometimes with /adf), but I've not yet tried this on the NFSv3 bits.

TCPIP> MOUNT DNFS0: volume_label logical_name  -

/path="/export/path" /host=nfs.example.com -

/structure=5/noadf

ACCVIOs from system components are VMS (or in this case, TCP) bugs.

[Volker Halle]

Mike,

I've tried your full command on TCPIP V5.6 ECO 5 NFS client and it works. Currently don't have access to a V8.4 system to try.

The NFS server does 'not see a mount' because the client NFS ACP crashes, before it can send anything to the NFS server. Can you try to set up a test NFS export on your local OpenVMS V8.4 server and try to mount that share in the same way ? Just to make sure, that this problem is reproducable without any 3rd party NFS server involved.

This most likely is a problem with the NFS client in TCPIP V5.7-13ECO2.  So please log a call with HP to do yourself and others, who are likely to run into this issue, a favor and get this problem addressed asap. And please suggest to HP, that they should include NFS sub-directory mounts in their quality testing.

Volker.

[Volker Halle]

Mike,

after building an OpenVMS Alpha V8.4 system, I tried your command with TCPIP V5.7 (without patches), it seems to work (against an OpenVMS V8.2 TCPIP V5.5 NFS server):

$ tcpip mount dnfs4:[nfs.save]/host=axpvms.invenate.local/path="/vms_nfs/nfs"/system/struc=5
%TCPIP$DNFSMOUNT-S-MOUNTED, /vms_nfs/nfs mounted on _DNFS4:[NFS.SAVE]

Exactly which version and architecture of OpenVMS and TCPIP are you running ($ TCPIP SHOW VERSION) ?

What's your NFS server ?

Volker.

[Volker Halle]

Mike,

after upgrading to TCPIP V5.7 ECO 2, I can reproduce your problem:

VTALPH $  tcpip mount dnfs4:[nfs.save]/host=axpvms.invenate.local/path="/vms_nfs/nfs"/system/struc=5
%%%%%%%%%%%  OPCOM  24-JUL-2011 16:52:27.14  %%%%%%%%%%%
Message from user SYSTEM on VTALPH
Client NFS ACP (0000042E) - fatal error detected, exiting
Signal arguments:

        00000005
        0000000C
        00000000
        00000070
        00068BA0
        0000001B

%TCPIP$DNFSMOUNT-E-DIRNOTCRE, _DNFS4:[NFS.SAVE] directory file not created
-SYSTEM-F-DEVNOTMOUNT, device is not mounted

The process then hangs, CTRL-Y $ EXIT causes it to go into RWAST state...

Definitely a reproducable problem with TCPIP V5.7 ECO 2. If you can, please log a call with HP !

Volker.

[Mike Fazio]

I'm not able to log a call with HP, I don't have an active support contract for my VMS servers. 

[Hoff]

No access to support or to newer fixes?  Then you are left with the obvious choices.  And yes, this is an unfortunate situation.  The payment of costs from those savings of not having support just came due, obviously.

[Volker Halle]

Mike,

this problem is solved after applying the following 2 images:

$ TCPIP SHOW VERSION/ALL
...

Network File System:
  TCPIP$DNFSACP;2                         V5.7-ECO2-22011  29-APR-2011  SYS$COMMON:[SYSEXE]
  TCPIP$DNFS_MOUNT_SHR;2     V5.7-ECO2-22011  29-APR-2011  SYS$COMMON:[SYSLIB]

One needs to contact HP to obtain these 'nfsv3pat' images. These fixed images are not yet available in any TCPIP ECO kit.

Volker.

[John_Malmberg]

I extracted the files from the original TCPIP V5.7 kit and put them in the respective directories and I can mount cygwin NFS images again.

[John_Malmberg]

Unfortunately as soon as I try to access files on the NFS mounted disks, the system bugchecks.

[Volker Halle]

John,

try mounting only DNFSx: without specifying a subdirectory. As fas as I remember, this did work with TCPIP V5.7 ECO 2.

Volker.

[John_Malmberg]

I was not specifying the subdirectory in the mount command, just the DNFS: which worked prior to installing the ECO.

I reinstalled the original ECO kit, so now I can not SSH X11 tunnel into my VMS 8.4 systems, but I can mount the cygwin disks again.