HP TCP/IP Services for OpenVMS
Management


Previous Contents Index


Chapter 23
Configuring and Managing the NFS Client

The Network File System (NFS) client software enables client users to access file systems made available by an NFS server. These files and directories physically reside on the remote (server) host but appear to the client as if they were on the local system. For example, any files accessed by an OpenVMS client --- even a UNIX file --- appear to be OpenVMS files and have typical OpenVMS file names.

This chapter reviews key concepts and describes:

For information about the NFS server, see Chapter 22.

23.1 Key Concepts

Because the NFS software was originally developed on and used for UNIX machines, NFS implementations use UNIX file system conventions and characteristics. This means that the rules and conventions that apply to UNIX file types, file names, file ownership, and user identification also apply to NFS.

Because the TCP/IP Services NFS client runs on OpenVMS, the client must accommodate the differences between the two file systems, for example, by converting file names and mapping file ownership information. You must understand these differences to configure NFS properly and to successfully mount file systems from an NFS server.

The following sections serve as a review only. If you are not familiar with these topics, see the HP TCP/IP Services for OpenVMS Concepts and Planning guide for a more detailed discussion of the NFS implementation available with the TCP/IP Services software.

23.1.1 NFS Clients and Servers

NFS is a client/server environment that allows computers to share disk space and users to work with their files from multiple computers without copying them to the local system. Computers that make files available to remote users are NFS servers. Computers with local users accessing and creating remote files are NFS clients. A computer can be an NFS server or an NFS client, or both a server and a client.

Attaching a remote directory to the local file system is called mounting a directory. A directory cannot be mounted unless it is first exported by an NFS server. The NFS client identifies each file system by the name of its mount point on the server. The mount point is the name of the device or directory at the top of the file system hierarchy. An NFS device is always named DNFSn.

All files below the mount point are available to client users as if they reside on the local system. The NFS client requests file operations by contacting a remote NFS server. The server then performs the requested operation. The NFS client automatically converts all mounted directories and file structures, contents, and names to the format required by OpenVMS. For example, a UNIX file named /usr/webster/.login would appear to an OpenVMS client as DNFS1:[USR.WEBSTER].LOGIN;1 .

For more information on how NFS converts file names, see Appendix C.

23.1.2 Storing File Attributes

The OpenVMS operating system supports multiple file types and record formats. In contrast, NFS and UNIX systems support only byte-stream files, seen to the OpenVMS client as sequential STREAM_LF files.

This means the client must use special record handling to store and access non-STREAM_LF files. The OpenVMS NFS client accomplishes this with attribute description files (ADFs). These are special companion files the client uses to hold the attribute information that would otherwise be lost in the translation to STREAM_LF format. For example, a SET FILE/NOBACKUP command causes the client to create an ADF, because NFS has no concept of this OpenVMS attribute.

23.1.2.1 Using Default ADFs

The client provides default ADFs for files with the following extensions: .EXE, .HLB, .MLB, .OBJ, .OLB, .STB, and .TLB. (The client does not provide ADFs for files with the .TXT and .C extensions, because these are STREAM_LF.) The client maintains these ADFs on the server.

For example, SYS$SYSTEM:TCPIP$EXE.ADF is the default ADF for all .EXE type files. When you create .EXE files (or if they exist on the server), they are defined with the record attributes from the single default ADF file. The client refers only to the record attributes and file characteristics fields in the default ADF.

23.1.2.2 How the Client Uses ADFs

By default, the client uses ADFs if they exist on the server. The client updates existing ADFs or creates them as needed for new files. If you create a non-STREAM_LF OpenVMS file or a file with access control lists (ACLs) associated with it on the NFS server, the NFS client checks to see whether a default ADF can be applied. If not, the client creates a companion ADF to hold the attributes.

The client hides these companion files from the user's view. If a user renames or deletes the orginal file, the client automatically renames or deletes the companion file. However, if a user renames or deletes a file on the server side, the user must also rename the companion file; otherwise, file attributes are lost.

You can modify this behavior with the /NOADF qualifier to the MOUNT command. The /NOADF qualifier tells the client to handle all files as STREAM_LF unless a default ADF matches. This mode is only appropriate for read-only file systems because the client cannot adequately handle application-created files when /NOADF is operational.

23.1.2.3 Creating Customized Default ADFs

You can create customized default ADFs for special applications. To do so:

  1. On the client, create a special application file that results in creating an ADF on the server. Suppose that application file is called TEST.GAF .
  2. On the server, check the listing for the newly created file. For example:


    > ls -a 
    . 
    .. 
    .$ADF$test.gaf;1 
    test.gaf 
     
    

    Note that the ADF ( .$ADF$test.gaf;1 ) was created with the data file ( TEST.GAF ).

  3. On the server, copy the ADF file to a newly created default ADF file on the client. For example:


    > cp .\$ADF\$test.gaf\;1 gaf.adf 
     
    

    Note that the backslashes (\) are required for entering the UNIX system nonstandard dollar sign ($) and semicolon (;) symbols.

  4. On the client, copy the new default ADF file to the SYS$SYSTEM directory. For example:


    $ COPY GAF.ADF SYS$COMMON:[SYSEXE]TCPIP$GAF.ADF 
    

  5. Dismount all the NFS volumes and mount them again. This starts another NFS ancillary control process (ACP) so that the newly copied default ADF file can take effect.

23.1.3 NFS Client Support for Extended File Specifications

The NFS client supports the extended character set supported by the OpenVMS operating system. Extended file specifications are provided by the ODS-5 file system.

The NFS client does not support NUL (ASCII 0). The length of a file name is limited to 232 characters, including the file name, dot, file extension, semicolon, and version number.

If you do not include the /STRUCTURE qualifier on the MOUNT command, the NFS client assumes that the file system structure being accessed is an ODS-2 volume. You can change this default by defining the following logical name:


TCPIP$NFS_CLIENT_MOUNT_DEFAULT_STRUCTURE_LEVEL 

You can use this logical name to ensure that all NFS disks on the system have ODS-5 support enabled. Set the value of the logical to 2 for ODS-2 (the default), or 5 for ODS-5. To override this logical, include the /STRUCTURE qualifier to the TCP/IP management command MOUNT.

To mount an ODS-5 volume, add the /STRUCTURE=5 qualifier to the TCP/IP management command MOUNT. For example:


$ TCPIP 
TCPIP> MOUNT DNFS0: BOOK1 BEATRICE - 
_TCPIP> /PATH="/INFERNO" /HOST="FOO.BAR.EREWHON" - 
_TCPIP> /OPTIONS=TYPELESS /STRUCTURE=5 /SYSTEM 

The /OPTIONS=TYPELESS qualifier is required because the path name did not include ".dir." If you specify ".dir" on the path, you do not need to include the /OPTIONS=TYPELESS qualifier.

The /STRUCTURE qualifier accepts the following values:

For more information about the MOUNT/STRUCTURE command, display the online help by entering the following command:


TCPIP> HELP MOUNT/STRUCTURE 

Note

When you display device information using the DCL command SHOW DEVICE/FULL, the NFS disk is incorrectly shown as being accessed by DFS. For example:


$ SHOW DEVICE/FULL 
...
Disk DNFS1:, device type Foreign disk type 7, is online, mounted, 
file-oriented device, shareable, accessed via DFS 
...

23.1.4 How the NFS Client Authenticates Users

Both the NFS server and NFS client use the proxy database to authenticate users. The proxy database is a collection of entries used to register user identities. To access file systems on the remote server, local users must have valid accounts on the remote server system.

The proxy entries map each user's OpenVMS identity to a corresponding NFS identity on the server host. When a user initiates a file access request, NFS checks the proxy database before granting or denying access to the file.

The proxy database is an index file called TCPIP$PROXY.DAT. If you use the configuration procedure to configure NFS, this empty file is created for you. You populate this file by adding entries for each NFS user. See Section 23.3 for instructions on how to add entries to the proxy database.

Note

The configuration procedure for the NFS server creates a nonprivileged account with the user name TCPIP$NOBODY. You might want to add a proxy record for the default user (-2/-2) that maps to the TCPIP$NOBODY account.

23.1.5 How the NFS Client Maps User Identities

Both OpenVMS and UNIX based systems use identification codes as a general method of resource protection and access control. Just as OpenVMS employs user names and UICs for identification, UNIX identifies users with a user name and a user identifier (UID) and group identifier (GID) pair. Both UIDs and GIDs are used to identify a user on a system.

The proxy database contains entries for each user wanting to access files on a server host. Each entry contains the user's local OpenVMS account name, the UID/GID pair that identifies the user's account on the server system, and the name of the server host. This file is loaded into dynamic memory when the NFS client starts. Whenever you modify the UID/GID to UIC mapping, you must restart the NFS client software by dismounting and remounting all the client devices. (Proxy mapping always occurs even when operating in OpenVMS to OpenVMS mode.)

The only permission required by the UNIX file system for deleting a file is write access to the last directory in the path specification.

You can print a file that is located on a DNFSn: device. However, the print symbiont, which runs as user SYSTEM, opens the file only if it is world readable or if there is an entry in the proxy database that allows read access to user SYSTEM.

23.1.6 NFS Client Default User

You can associate a client device with a user by designating the user with the /UID and /GID qualifiers to the MOUNT command. If you do not specify a user with the /UID and /GID qualifiers, NFS uses the default user --2/--2. If the local user or the NFS client has no proxy for the host serving a DNFS device, all operations performed by that user on that device are seen as coming from the default user (--2/--2).

To provide universal access to world-readable files, you can use the default UID instead of creating a proxy entry for every NFS client user.

HP strongly recommends that, for any other purposes, you provide a proxy with a unique UID for every client user. Otherwise, client users may see unpredictable and confusing results when they try to create files.

23.1.7 How the NFS Client Maps UNIX Permissions to OpenVMS Protections

Both OpenVMS and UNIX based systems use a protection mask that defines categories assigned to a file and the type of access granted to each category. The NFS server file protection categories, like those on UNIX systems, include: user, group and other , each having read ( r ), write ( w ), or execute ( x ) access. The OpenVMS categories are SYSTEM, OWNER, GROUP, and WORLD. Each category can have up to four types of access: read (R), write, (W), execute (E), and delete (D). The NFS client handles file protection mapping from server to client.

OpenVMS delete access does not directly translate to a UNIX protection category. A UNIX user can delete a file as long as he or she has write access to the parent directory. The user can see whether or not he or she has permissions to delete a file by looking at the protections on the parent directory. This design corresponds to OpenVMS where the absence of write access to the parent directory prevents users from deleting files, even when protections on the file itself appear to allow delete access. For this reason, the NFS client always displays the protection mask of remote UNIX files as permitting delete access for all categories of users.

Since a UNIX file system does not have a SYSTEM protection mask (the superuser has all permissions for all files) the NFS client displays the SYSTEM as identical to the OWNER mask.

23.1.8 Guidelines for Working with DNFS Devices

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

23.1.9 How NFS Converts File Names

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:

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

23.3 Registering Users in the Proxy Database

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:

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.

Table 23-1 Required Fields for NFS Proxy Entries
Field Meaning
OpenVMS user name Name of the NFS user's OpenVMS account
Type Direction of NFS communication allowable to the user. Specify one of the following:
  • O (outgoing). Used by the NFS client.
  • N (incoming). Used by the NFS server.
  • ON (outgoing and incoming). Used by both client and server.
  • D (dynamic). Entry is loaded in the server's dynamic memory. When the NFS server starts, it creates a copy of the proxy database in dynamic memory. (If the account does not exist or the account is disabled, the entry for the account will be missing from dynamic memory.)
UID/GID pair Remote identity of the user. Required even if both client and server are OpenVMS hosts.
Remote host name Name of the remote host, which is one of the following:
  • Remote client of the local NFS server
  • Remote server for the local NFS client
  • Both
  • Wildcard ( *) for all hosts

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 
 

23.4 Mounting Files and Directories

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:

For example:


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

Note

By default, a mount is considered a system mount and privileges are required unless the /SHARE qualifier is used. See Section 23.4.1 for information on user-level mounting.

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:

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


Previous Next Contents Index