Determining NFS client mounts from the VMS Server

[Brian Reiter]

Hi Folks,

From OpenVMS (NFS Server) is there a way of determining which clients have NFS mounts active? I could in principal skim through the operator.log file and pick up the mount/dismount requests, just wondering if there is another way.

We're using TCPIP 5.4 ECO 5

Regards, and thanks for your help.


Brian

[Wim Van den Wyngaert]

UCX sho servi nfs/fu
-> protocol used is UDP per default.

UDP is stateless. There is no connection active for mounted shares.

Never tried NFS in TCP mode yet.

Wim

[Wim Van den Wyngaert]

A list of clients that have mounted the share can normally be found in rmtab on Unix.

In my log file of NFS mountd I found messages "cannot dump mountlist to tcpip$etc:mountdtab.dat". May be that's the undocumented alternative of rmtab ?

Is "ucx show mount/all" showing anything ?

I created it as a flat file : no improvements. Boot server. Idem. Google didn't find any doc.

Wim

[Brian Reiter]

From the VMS clients the TCPIP SHO MOUNT works fine, however there could be a number of architectures (Windoze,Unix,Linux and VMS) participating as NFS clients and it would be good to grab all the info from the server side (no need then to worry about different RSH scripts depending on client type).

TCPIP SHO NFS gives come clues as to what's going on but doesn't show the current mounts.

[Volker Halle · Accepted solution]

Brian,

I'm running TCPIP V5.5:

SYS$SPECIFIC:[TCPIP$ETC]MOUNTDTAB.DAT

seems to contain the desired data, but it's accessed by TCPIP$MOUNTD_1 exclusively, so it's quite hard to get to it's contents. I found the file header in INDEXF.SYS, obtained the LBN and used the DISKBLOCK (OpenVMS Freeware) utility to read and dump the contents of the file.

It seems to contain information like this:

remote_node:/local_file_system

If the local file system has been dismounted by the remote NFS client, the first character of the remote_node name seems to be replaced by '#'.

Volker.

[Brian Reiter]

Now thats handy, just did a BACKUP/IGNORE=INTERLOCK to see what was in it. Definitly looks like the kind of thing I need. Don't need to do it very often, a snapshot every couple of hours should suffice for my purpose.

Many thanks

Brian

[Wim Van den Wyngaert]

Wonder what it does when a node crashes and stays down. To my knowledge there is no keepalive in NFS and thus the entry will stay in the list.

Volker : what is the char of the file ? I created it empty but still get invalid device in the log file (or is there a logical ? The error message gives the full name.)

Wim

[Wim Van den Wyngaert]

BTW : anyone with 5.3 eco 2 who has the file ?

Wim

[Brian Reiter]

FWIW, it looks like a TCPIP DISM/ALL isn't reflected by the server, nor does it seem that old entries are removed after a client restart.

Still better than nothing though.

[Wim Van den Wyngaert]

Just "stripped" the mountd exe. No logical for the file. And the file is gone after a reboot.

Wim

[Wim Van den Wyngaert]

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN4/0170____.HTM

explains some things.

Wim

[Volker Halle]

Wim,

in TCPIP V5.5, this file is accessed via TCPIP$ETC:MOUNTDTAB.DAT - a sequential STREAM_LF file.

In this version of TCPIP a TCPIP DISM from a client seems to be reflected in that file by replacing the first character of the remote:/local_file_system entry with a '#' character. Certainly only an explicit TCPIP DISM will cause the entry to be 'invalidated'. The mountdtab man page link provided above explains this as well.

As this file does not seem to be mentioned in the TCPIP documentation, usage of this file is probably considered unsupported.

Volker.

[Brian Reiter]

Got some form of workaround now.

Many thanks


Brian