If you plan to export file systems to PC-NFS client hosts, you must enable PC-NFS using TCPIP$CONFIG. The PC-NFS process starts automatically.

You can also use the following commands to manage PC-NFS:

• DISABLE SERVICE PCNFS (temporarily disables PC-NFS)
• ENABLE SERVICE PCNFS (enables PC-NFS)
• SHOW SERVICE PCNFS (displays information used for troubleshooting)

For information about setting up PC-NFS for printing, see Chapter 24.

20.5 Managing the MOUNT Service

The MOUNT service responds to Version 1 of the MOUNT protocol, which is used with Version 2 of the NFS protocol. It also supports Version 3 of the MOUNT protocol, which is used with Version 3 of the NFS protocol.

The MOUNT service is started automatically when you start the NFS server (for example, using TCPIP$NFS_SERVER_STARTUP.COM).

You can customize the operation of the MOUNT service by using SYSCONFIG to modify the attributes listed in Table 20-1.

Table 20-1 MOUNT Attributes

Attribute	Description
mountd_option_a	Verifies the Internet addresses of hosts that make mount and unmount requests. If a client's address cannot be translated into a host name by the gethostbyaddr() function and is then translated back into the same Internet address by the gethost-byname() function, the request is rejected. Requires name resolution to be enabled.
mountd_option_d	Turns on Internet address verification and domain checking. If you are running the BIND service, MOUNT verifies that a host making a mount or unmount request is in the server's domain.
mountd_option_i	Verifies the Internet address of hosts that make mount and unmount requests. If a client's address cannot be translated into a host name by the gethostbyaddr() function, the request is rejected. Requires name resolution to be enabled. If the mountd_option_i attribute is not set, and a client's address cannot be translated, the address is converted to a string in the form xx.xx.xx.xx. This allows users to access exported file systems that have a wildcard (*) (allow everybody) as their host list. The mountd_option_i attribute is automatically enabled when either the mountd_option_d or the mountd_option_s attribute is specified.
mountd_option_n	Allows nonroot mount requests to be served. In previous versions of TCP/IP Services, the servicing of nonroot mount requests was allowed by default. With this version, this attribute must be set to allow nonroot mount requests. Specify this attribute only if there are clients (such as desktop computers) that require it.
mountd_option_s	Turns on Internet address verification and subdomain checking. If you are running the BIND service, the MOUNT service verifies that a host making a mount or unmount request is in the server's domain or subdomain.

See Section 20.12 for information about using the SYSCONFIG command.

20.6 Registering Users and Hosts

In a NFS environment shared by UNIX hosts, a common user authorization domain may be used. In this configuration, each user's UID is unique for all the hosts. On OpenVMS, however, the user authorization file (UAF) cannot be shared, but client user identifiers must be mapped to OpenVMS accounts. Therefore, users on client hosts must have corresponding OpenVMS accounts on the OpenVMS NFS server.

To establish this common allocation on OpenVMS, each client UID must be mapped to a unique OpenVMS account. This arrangement requires a separate OpenVMS account for each NFS client. It is possible to use the same OpenVMS account for multiple users, but this is not recommended for accounts in which users have read or edit access to files.

After setting up appropriate accounts, you must register users in the proxy database and set mount points in the export database.

20.6.1 Adding Proxy Entries

Each user accessing your local server must be registered in the proxy database. See Section 20.1.3 if you are not familar with how the server uses this database to grant access to remote users. You should create the proxy database before the NFS server starts. If you are adding proxies, create the OpenVMS accounts before creating the proxy entries.

An empty proxy database file, TCPIP$PROXY.DAT, is created for you when you first use the TCPIP$CONFIG configuration procedure to configure NFS. This file is empty until you populate it with proxy entries for each NFS user. If you do not use TCPIP$CONFIG to configure NFS, use the CREATE PROXY command to create the empty database file. The file TCPIP$PROXY.DAT resides in the SYS$COMMON:[SYSEXE] directory.

Use the ADD PROXY, REMOVE PROXY, and SHOW PROXY commands to maintain the proxy database. Enter these commands at the TCPIP prompt:

TCPIP> ADD PROXY user_name /UID=nn /GID=nn /HOST=host_name

For example, you can use the following command to register a user:

TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST="june"

You can specify a list of hosts for which the UID and GID are valid. For example:

TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST=("APRIL","MAY","JUNE")

You can also specify that all hosts are valid using an asterisk (*) wildcard character. For example:

TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST=*

20.6.2 Adding Entries to the Export Database

If you use the configuration procedure to configure NFS, the export database is created for you, if it does not already exist. This file is empty until you populate it with mount point entries. If you do not use TCPIP$CONFIG to configure NFS, use the CREATE EXPORT command to create the empty database file.

Use the ADD EXPORT, REMOVE EXPORT, and SHOW EXPORT commands to maintain the export database. Enter these commands at the TCPIP prompt:

TCPIP> ADD EXPORT "/path/name" /HOST=host_name

See the Compaq TCP/IP Services for OpenVMS Management Command Reference manual for more information about these commands and command qualifiers.

You can identify mount points by any of the following methods:

• OpenVMS device name
• A device name and directory
• A logical name

You can back up NFS-mounted files using standard OpenVMS backup procedures. For more information, see the OpenVMS documentation.

If you back up an OpenVMS file system or a container file system while remote users are accessing the files, the resulting save set may contain files that are in an inconsistent state. For a container file system, there is the additional danger that the container file itself may be in an inconsistent state.

Furthermore, the OpenVMS Backup utility does not issue warning messages when backing up files that are opened by the NFS server, even when the /IGNORE=INTERLOCK qualifier to the BACKUP command was not used.

The approach to backing up is to schedule the backup for a time when users will not be accessing the files. Then either unmap the file systems to be backed up or shut down the NFS server.

If you perform an incremental backup (using the /SINCE=MODIFIED qualifier to the BACKUP command) on container file systems, a separate copy of the container must also be backed up because the container file's modification date never changes. See Section 20.9 for information about setting up container file systems; see Section 20.10 for information about managing container file systems.

20.8 Setting Up and Exporting an OpenVMS File System

The following example describes how to set up an OpenVMS file system on the OpenVMS server and how to make the file system available to Joe Brown, a user on UNIX client ultra .

Joe Brown has an OpenVMS user name of BROWN and a UNIX user name of joe .

1. Log in to a UNIX node to find the UID/GID for the UNIX user joe by entering the following command:

   % grep joe /etc/passwd joe: (encrypted password) :27:58: ...

   
   The fields :27:58 of the password entry for joe are the UID and GID. In this example, joe has UID=27 and GID=58.

2. Log in to the OpenVMS server.
   The OpenVMS files exist on DSA301:[BROWN.TEST]. Joe wants to export the files in the subdirectory TEST to his UNIX machine, ultra .
3. Enter the following commands:

   $ TCPIP TCPIP> ADD PROXY BROWN /UID=27 /GID=58 /HOST=ultra TCPIP> MAP "/vmsdisk" DSA301: TCPIP> ADD EXPORT "/vmsdisk/brown/test" /HOST=ultra

   
   If you want to make the mapping permanent, enter a SET CONFIGURATION MAP command.

If users need to create files with case-sensitive names or names containing characters that do not conform to the OpenVMS syntax, you can enable name conversion, which gives users more file-naming flexibility without creating a container file system. Use the /OPTIONS=NAME_CONVERSION qualifier to the command ADD EXPORT to enable this option.

With the NAME_CONVERSION option set, users can create files and directories in an OpenVMS file system using names that do not conform to OpenVMS file-naming rules.

For more information about file name conversion, see Appendix C.

20.9 Setting Up and Exporting a Container File System

A container file system is similar to a UNIX file system. When you create a container file system, you must specify an owner, using the /USER_NAME qualifier to the CREATE CONTAINER command.

When a container file system is created, a container directory is created, along with a container file in it. This container file provides compatibility with UNIX file storage attributes, such as file names, date and time stamps, UNIX protection masks, and UID ownership. If a container file system called NFS is created, it may look like the following example:

$ DIR DKA0:[NFS] Directory DKA0:[NFS] 00012201$BFS.DIR;1 NFS.CONTAINER;1 Total of 2 files.

The files contained within the directory should not be manipulated directly within OpenVMS except in the case of incremental backups, which require a separate backup of the container file.

If the container file system is for the use of just one remote user, that user can be the owner. If it is for the use of several users, the owner should be a user whose UIC is mapped to UID=0/GID=1 (UNIX user root). In either case, the name set with this qualifier must already be registered in the proxy database. This user also becomes the owner of the internal root directory of the container.

To create a container file system on the NFS server, follow these steps:

1. Add a proxy entry for the owner of the container file system.

   TCPIP> ADD PROXY SYSTEM /UID=0 /GID=1 /HOST=*

2. Create an empty container file system on an OpenVMS volume, assign an owner, and set permissions.

   TCPIP> CREATE CONTAINER DSA101:[TEST] /USER_NAME=SYSTEM - _TCPIP> /ROOT_MODE=751 /HOST="june"

   
   The preceding example creates a container file system named TEST on device DSA101:. The user with a UID of 0 is assigned as owner. The permissions are assigned as follows:

   Owner: read, write, and execute (7)
   Group: read and execute (5)
   World: execute (1)

3. Map the OpenVMS volume on which the container file has been created.

   TCPIP> MAP "/test_dsk" DSA101:

   
   Note that it is important to map the underlying volume before mapping the container file system to make it available to the NFS server and the management control program. It is possible to use a volume both as an OpenVMS style file system and a container file system. If the disk was already in use as a OpenVMS style file system, it may already be mapped. In that case, you can skip this step.

4. Map the container file system to make it available to NFS client hosts. This mapping gives the file system its UNIX style name and UNIX style attributes. For example:

   TCPIP> MAP "/test" DSA101:[TEST]

   
   To make the mappings permanent, also use the SET CONFIGURATION MAP command.

5. If you do not already have proxies for the users, create them now. For example:

   TCPIP> ADD PROXY USER1 /UID=234 /GID=14 /HOST=*

6. In the root directory, create a top-level directory for each remote user. Be sure to specify directory ownership and set file permissions as needed for your environment. For example,

   TCPIP> CREATE DIRECTORY "/test/user1" /USER_NAME=USER1 /MODE=751 /HOST="june"

7. Export the root directory or the user top-level directories in the container file system. To export the root directory, enter:

   TCPIP> ADD EXPORT "/test" /HOST=*

   
   To export the user top-level directory, enter:

   TCPIP> ADD EXPORT "/test/user1" /HOST="june"

This section reviews the commands you use to maintain and examine a container file system. Topics include:

• Displaying directory listings
• Copying files
• Removing links to a file or directory
• Deleting files
• Verifying the integrity of the file system
• Rebuilding the container file system

For complete command descriptions, see the Compaq TCP/IP Services for OpenVMS Management Command Reference manual.

20.10.1 Displaying Directory Listings

Use the DIRECTORY command to display the contents of a directory. For example,

TCPIP> DIRECTORY "/path/name"

In this example, /path/name is a valid UNIX directory specification that begins with a slash (/) and is enclosed in quotation marks.

The DIRECTORY command has the following qualifiers:

• /FULL specifies that a comprehensive list of information is displayed for each file displayed by the DIRECTORY command. The default provides a brief listing of the files in the directory.
• /VMS provides the corresponding OpenVMS file name for each file in the directory.

You cannot use the DCL command COPY to create files in a container file system, because the UNIX directory structure is fully contained in the corresponding container file. Instead, you must use the TCP/IP Services IMPORT command to copy a file from an OpenVMS directory into a container file system. Similarly, use the TCP/IP Services EXPORT command to copy a file from a container file system into an OpenVMS directory.

If the OpenVMS data file does not have the STREAM_LF record format, it will automatically be converted to STREAM_LF. Use the /NOCONVERT qualifier to prevent the conversion.

20.10.3 Removing Links to a File

A link is a directory entry referring to a file. A file can have several links to it. A link (hard link) to a file is indistinguishable from the original directory entry. Any changes to the file are independent of the link used to reference the file. A file cannot be deleted (removed) until the link count is zero.

Users can create multiple links to a file. A user sometimes creates a link to a file so that the file appears in more than one directory.

All links to a file are of equal value. If a file has two links and one link is removed, the file is still accessible through the remaining link. When the last existing link is removed (the link count is zero), the file is no longer accessible and is deleted.

Remove links to a file with the REMOVE FILE command. For example, to remove the link to a file named letter located at /usr/smith , enter the following command:

TCPIP> REMOVE FILE "/usr/smith/letter"

20.10.4 Removing Links to a Directory

Like UNIX files, UNIX directories have links to them. An empty directory is deleted when the last link to the directory is removed.

Remove links to a UNIX directory with the REMOVE DIRECTORY command. For example, to remove the directory smith at /usr , enter the following command:

TCPIP> REMOVE DIRECTORY "/usr/smith"

20.10.5 Deleting a Container File System

You can delete a container file system with all its directories and files by issuing the DELETE CONTAINER command. For example, to delete the UNIX container created on WORK1$:[GROUP_A], enter the following command:

TCPIP> DELETE CONTAINER WORK1$:[GROUP_A]

Use the UNMAP command to unmap the container file system before you delete it.

20.10.6 Verifying the Integrity of a Container File System

You may want to verify the integrity of your container file system under the following circumstances:

• If you are experiencing disk read or write errors or encountering problems backing up the container.
• If you are making copies or restoring files from a backup.
  The container file records the volume label and the Files--11 file identifiers of the actual files on the disk. If you copy the file system or change the volume label, you must run ANALYZE CONTAINER/REPAIR after you copy the files so that the file identifiers and volume label are corrected for the new location of the files.
• During system startup after a system failure.

You can use the ANALYZE CONTAINER command to check the integrity of your container file system. This command is similar in function to the DCL ANALYZE/DISK_STRUCTURE command.

Before analyzing the container file system, unmap it to prevent access to it during the analysis.

For example, to verify the integrity of a container file system called /GroupA located in WORK1$:[GROUP_A], enter the following commands:

TCPIP> UNMAP "/GroupA" TCPIP> MAP "/group_a" WORK1$: TCPIP> ANALYZE CONTAINER WORK1$:[GROUP_A]

File system access to the container file is suspended while the container is being analyzed.

Table 20-2 lists the components of a container file system that are normally verified by the ANALYZE CONTAINER command.

Table 20-2 Container File System Components Analyzed

UNIX Item	OpenVMS Conceptual Equivalent	Description
Super block	Home block	Contains the basic information on the internal structuring of the container file.
Inode	File header	Each file or directory has an inode that contains information describing the file. The inode is a central definition of the file.
Directory	Directory	Contains the file names and directory hierarchy information. File name entries contain links to the inode information.
Bitmap	BITMAP.SYS	Contains the container file internal allocation information. Only one bitmap exists in the container file.

For a complete description of the ANALYZE CONTAINER command and its qualifiers, see the Compaq TCP/IP Services for OpenVMS Management Command Reference manual.