HP OpenVMS Systems Documentation

The following list summarizes the guidelines and restrictions associated with DNFS devices:

• BACKUP and RESTORE operations
  The OpenVMS NFS client does not emulate the on-disk structure of actual OpenVMS disks. Therefore, applications that need direct knowledge of the OpenVMS on-disk structure, such as image backup and restore, work differently with DNFSn: volumes than with other volumes.
• File identification
  The NFS client constructs OpenVMS file identifiers (FIDs) dynamically. The remote NFS server does not store them. Each NFS client constructs its own FIDs, possibly leading to different FIDs of the same file for different NFS clients.
• Disk quotas
  Disk quotas for OpenVMS disks are not applicable to DNFSn: disks.

Because NFS uses UNIX style syntax for file names, valid OpenVMS file names may be invalid on the NFS server and vice versa. The NFS software automatically converts file names to the format required by either the client or the server. (NFS always converts file names even when both the NFS client and the NFS server are OpenVMS hosts.)

All name-mapping sequences on the OpenVMS client begin with the dollar sign ($) escape character. Appendix C lists the rules that govern these conversions and provides a list of character sequences, server characters, and octal values used for NFS name conversion.

23.2 NFS Client Startup and Shutdown

The NFS client can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$NFS_CLIENT_STARTUP.COM allows you to start up the NFS client independently.
• SYS$STARTUP:TCPIP$NFS_CLIENT_SHUTDOWN.COM allows you to shut down the NFS client independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$NFS_CLIENT_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the NFS client is started.
  For example, use this file to store systemwide MOUNT commands.
• SYS$STARTUP:TCPIP$NFS_CLIENT_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked immediately before the NFS client is shut down.

Users on your client host must have corresponding accounts on the NFS server host. After making sure client users have appropriate accounts, you must register them with the proxy database. The NFS client, the NFS server, and the PC-NFS daemon all use the proxy database.

If you use TCPIP$CONFIG to configure NFS, the index file TCPIP$PROXY.DAT is created for you. This file is empty until you populate it with proxy entries. If you do not use the configuration procedure, use the CREATE PROXY command to create the empty database file. The file TCPIP$PROXY.DAT resides in the SYS$COMMON:[SYSEXE] directory by default. You can change the location of the proxy database by redefining the logical name TCPIP$PROXY. (You can also create a proxy database file from a UNIX formatted /etc/password file by using the CONVERT/VMS PROXY command.)

Use the following TCP/IP management commands to manage the proxy database:

• ADD PROXY
• REMOVE PROXY
• SHOW PROXY

For example:

TCPIP> ADD PROXY username /NFS=type /UID=n /GID=n /HOST=host_name

Changes in the proxy database take effect only after you dismount all DNFSn: devices and remount them. An exception is DNFS0:, which is present if the NFS client driver is loaded and cannot be mounted or dismounted.

Each entry in the proxy database has the fields that are listed in Table 23-1.

To add a user name to the proxy database, take the following steps:

1. For each NFS user, obtain the OpenVMS user name from the OpenVMS user authorization file (UAF). If a user name is not in the UAF, use the OpenVMS Authorize utility to add it.
2. Obtain the UID/GID pair for each NFS user from the /etc/password file on the NFS server.
3. Enter SHOW PROXY.
4. Enter ADD PROXY for each NFS user you want to add to the proxy database. For example:

   TCPIP> ADD PROXY GANNET /NFS=(OUTGOING,INCOMING) /UID=1111 /GID=22 /HOST=CLIENT1

5. Reenter SHOW PROXY to confirm the new information.

The following illustrates a portion of a proxy database file:

VMS User_name     Type      User_ID    Group_ID   Host_name

GANNET            OND          1111          22   CLIENT1, client1
GEESE             OND          1112          22   *
GREBE             OND          1113          22   client1, client2
GROUSE            OD           1114          23   client3
GUILLEMOT         OD           1115          23   client3
GULL              OD           1116          23   client4

Attaching remote files and directories exported by an NFS server is called mounting. The NFS client identifies each file system by the name of its mount point on the server. The client provides the following TCP/IP management commands:

• MOUNT
• SHOW MOUNT
• DISMOUNT

For example:

TCPIP> MOUNT mount_point /HOST="host" /PATH="/path/name"

When you issue a MOUNT command, the NFS client creates a new DNFS device and mounts the remote file system onto it. For example, the following command mounts, onto local device DNFS2:, the remote directory /usr/users/curlew , which physically resides on NFS server loon .

TCPIP> MOUNT DNFS2: /HOST="loon" /PATH="/usr/users/curlew"

After entering the command, a confirmation message such as the following is displayed:

%DNFS-S-MOUNTED, /users/curlew mounted on DNFS2:[000000]

If you specify DNFS0 in a mount command, the client selects the next available unit number for you, for example:

MOUNT DNFS0:/HOST="loon" /PATH="/usr/curlew"
%DNFS-S-MOUNTED, /usr/curlew mounted on DNFS3:[000000]

Qualifiers to the MOUNT command let you modify the way a traditional mount occurs. For example, you may specify background mounting, modify existing mounts, or hide subdirectories from view. See the following sections for more information:

• User-level mounting ( Section 23.4.1)
• Automounting ( Section 23.4.2)
• Background mounting ( Section 23.4.3)
• Overmounting ( Section 23.4.4)
• Occluded mounting ( Section 23.4.5)

See the HP TCP/IP Services for OpenVMS Management Command Reference manual for a complete list of MOUNT options and command qualifiers.

23.4.1 User-Level Mounting

The NFS client supports shared mounting by using the /SHARE qualifier with the MOUNT command. Any user can mount a file system using the /SHARE qualifier---SYSNAM or GRPNAM privileges are not required. The /SHARE qualifier places the logical name in the job logical name table and increments the volume mount count, regardless of the number of job mounts. When the job logs out, all job mounts are dismounted, which causes the volume mount count to be decremented.

The following example illustrates how to specify a shared mount:

TCPIP> MOUNT DNFS1: /HOST=BART /PATH="/DKA100/ENG"
TCPIP> MOUNT DNFS1: /HOST=BART /PATH="/DKA100/ENG" /SHARE

This mount request increments the mount count by 1. You must specify the /SHARE qualifier with the same host name and path as used in the initial mount to ensure that the mount is seen as a shared mount instead of as a new mount request.

With a shared mount, the mount requests increment the mount count by 1 under the following circumstances:

• With an initial /SYSTEM or /GROUP mount.
• With a DCL command MOUNT/SHARE or a TCP/IP management command MOUNT/SHARE that completes without an error. (This contrasts with overmount, where the previous mounting point is dismounted. This condition can increment or decrement the mount count or leave it unchanged.)

In this way, if the main process of the job logs out, the job mount is deallocated, and the volume mount count decrements by 1 (if zero, the device is dismounted). OpenVMS handles dismounting differently based on whether you use the TCP/IP management command DISMOUNT or the DCL command DISMOUNT. These differences are as follows:

• With the TCP/IP command DISMOUNT, the NFS ACP dismounts one or (in the case of /ALL) more mount points. If the mount point being dismounted is the only or last one for the device, the device is dismounted for all users who mounted it, and the mount count is decremented to zero. If more that one mount point exists, the mount point is dismounted along with a specifically shared mount.
• With the DCL command DISMOUNT, the OpenVMS operating system checkes for job mounts first. If a job mount for the specified device exists, the /JOB mount is dismounted, any logical name associated with the /JOB mount is deallocated, and the mount count is decremented by one. If no JOB mount exists, OpenVMS checks for /SYSTEM and /GROUP mounts. If one exists, and the user has the required privilege, the /SYSTEM or /GROUP mount is dismounted, any associated logical name is deallocated, and the mount count is decremented by 1. No mount points are dismounted until the mount count reaches zero.
  If the user does not have the required SYSNAM or GRPNAM privilege, the following error message is returned:

  SYSTEM-F-NO-PRIVILEGE, operation requires privilege

  
  If no /SYSTEM or /GROUP mount exists, the following error message is returned:

  %DISM-W-CANNOTDMT, NFSn: cannot be dismounted %SYSTEM -F -DEVNOTMOUNT, device is not mounted

Consider the mount counts in the following sample MOUNT/DISMOUNT sequence:

1. TCPIP> MOUNT DNFS1:[A] /HOST=BART /PATH="/DKA0/ENG"/
   Mount count: 1 system mount, not incremented
2. TCPIP> MOUNT DNFS1:[A] /HOST=BART /PATH="/DKA0/ENG" /SHARE
   Mount count: 2 (incremented)
3. $ MOUNT/SHARE DNFS1:
   Mount count: 3 (incremented)
4. TCPIP> MOUNT DNFS1:[B] /HOST=MARGE /PATH="DKA0/TEST"
   Mount count: 3 (system mount, not incremented)
5. TCPIP> DISMOUNT DNFS1:[A]
   Mount count: 2
6. $ DISMOUNT DNFS1:
   Mount count: 1 (removed mount in example 3, decremented)
7. $ DISMOUNT DNFS1:
   Mount count: 0 (removed mount in example 4, decremented)

The original mount for BART "/ENG" on DNFS1:[A], along with its shared mount, is dismounted. The subsequent DISMOUNT commands dismount examples 3 and 4, leaving nothing mounted.

23.4.2 Automounting

Automounting allows you to mount a remote file system on an as-needed basis. This means that the client automatically and transparently mounts a remote server path as soon as the user accesses the path name.

Automounting is convenient for file systems that are inactive for large periods of time. When a user on a system invokes a command to access a remote file or directory, the automount daemon mounts the file and keeps it mounted as long as the user needs it. When a specified amount of time elapses without the file being accessed, it is dismounted. You can specify an inactivity period (5 minutes is the default), after which the software automatically dismounts the path.

You specify automounting and an inactivity interval with the qualifier /AUTOMOUNT=INACTIVITY:OpenVMS_delta_time.

The inactivity interval is the maximum inactive period for the mount attempt. When this period expires, the NFS client dismounts the path name as described below.

In this example, the client automounts directory /usr/webster residing on host robin onto the OpenVMS mount point DNFS67:. When it references the path name, the client keeps the path mounted unless it reaches an inactive period of 10 minutes, after which it dismounts the file system. With subsequent references, the client remounts the file system. For example:

TCPIP> MOUNT DNFS67: /HOST="robin" -
_TCPIP> /PATH="/usr/webster" /AUTOMOUNT=INACTIVITY=00:10:00

Background mounting allows you to retry a file system mount that initially failed. For example, you may have set mount points in your system startup command file so they are automatically mounted every time your system reboots. In this scenario, if the server is unavailable (because, for example, the server is also rebooting), the mount requests fail. With background option set, the client continues to try the mount after the initial failure. The client continues trying up to 10 times at 30-second intervals (default) or for the number of retries and interval you specify.

If you specify background mounting, you should also use the /RETRIES qualifier with a small nonzero number. This qualifier sets the number of times the transaction itself should be retried. Specify background mounting, along with the desired delay time and retry count parameters, with the qualifier /BACKGROUND=[DELAY:OpenVMS_delta_time,RETRY:n].

For example, the following command attempts to mount in background mode, on local device DNFS4:, the file system /flyer , which physically resides on host migration . If the mount fails, the NFS client waits 1 minute and then retries the connection up to 20 times. For example:

TCPIP> MOUNT DNFS4: /HOST="migration" /PATH="/flyer" -
_TCPIP> /BACKGROUND=(DELAY:00:01:00, RETRY:20) /RETRIES=4

If you use the /BACKGROUND qualifier, HP strongly recommends that you also use the /RETRIES qualifier specifying a nonzero value. If you use the default value for /RETRIES (zero), the first mount attempt can never complete except by succeeding, and the process doing the mount will hang until the server becomes available.

23.4.4 Overmounting

Overmounting allows you to mount another path onto an existing mount point. Specify overmounting with the /FORCE qualifier. The client dismounts the original mount point and replaces it with a new one.

Mounting a higher or lower directory level in a previously used path is also an overmount. For example, an overmount occurs when you execute two MOUNT commands in the following order:

TCPIP> MOUNT DNFS123:[USERS.MNT] /HOST="robin" /PATH="/usr"

%DNFS-S-MOUNTED, /usr mounted on _DNFS123:[USERS.MNT]

TCPIP> MOUNT DNFS123:[USERS.MNT] /HOST="robin" /PATH="/usr/tern" /FORCE

%DNFS-S-REMOUNTED, _DNFS123:[USERS.MNT] remounted as /usr/tern on ROBIN

The second MOUNT command specifies a lower level in the server path. This constitutes another path name and qualifies for an overmount.

23.4.5 Occluded Mounting

Occluded mounting allows you to mount a file system onto a client mount point that is higher or lower in the directory structure than an existing, active mount. This is different from overmounting because dismounting does not occur. Instead, the client occludes (hides from view) the subdirectories that are added to or dropped from the original mount specification when you perform a directory listing.

Specify the /FORCE qualifier with an occluded mount.

In the following example, the mount point specification was backed up one subdirectory from the previous one. If you enter the SHOW MOUNT command, both mounts are visible. However, if you enter DIRECTORY for DNFS2:[USERS.SPARROW], [.MNT] is no longer visible. To make this subdirectory visible again, issue the DISMOUNT command to dismount DNFS2:[USERS.SPARROW].

TCPIP> MOUNT DNFS2:[USERS.SPARROW.MNT] /HOST="birdy" /PATH="/usr"

%DNFS-S-MOUNTED, /usr mounted on _DNFS2:[USERS.SPARROW.MNT]

TCPIP> MOUNT DNFS2:[USERS.SPARROW] /HOST="birdy" /PATH="/usr" /FORCE

%DNFS-S-MOUNTED, /usr mounted on _DNFS2:[USERS.SPARROW]
-TCPIP-I-OCCLUDED, previous contents of _DNFS2:[USERS.SPARROW] occluded

The following example shows a mount of UNIX directory /usr to the OpenVMS device and directory DNFS3:[0,0].

On the UNIX host, the directory listing looks like this:

unix% ls
grebe wings pratincole

To do the mount, enter:

$ TCPIP MOUNT DNFS3: /HOST="unix" /PATH="/usr"

To check that the mount succeeded, enter:

$ TCPIP SHOW MOUNT DNFS3: /FULL
.
.
.

On the OpenVMS host, the directory listing looks like this:

$ DIRECTORY [0,0]

Directory DNFS3:[000,000]

GREBE.DIR;1  WINGS.DIR;1   PRATINCOLE.DIR;1

Total of 3 files.