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

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

• DISABLE SERVICE PCNFS (temporarily disables the daemon)
• ENABLE SERVICE PCNFS (enables the daemon)
• SHOW SERVICE PCNFS (displays information used for troubleshooting)

Users on client hosts must have corresponding OpenVMS accounts on your NFS server host. These accounts can be unique for each user or you can use the same OpenVMS account for multiple users². Choose UICs that match the intended work style. If you have users in the same work group who share files, assign the users' UICs in the same group.

If you have multiple users accessing one OpenVMS account, be sure to set file limits to provide satisfactory performance for all users accessing this account. See Section 16.13.9 for more information.

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

16.5.1 Adding Proxy Entries

Each user accessing your local server must be registered in the proxy database. See Section 16.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 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 the configuration procedure 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 (*), as shown in the following example:

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

16.5.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 the configuration procedure 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 DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual for more information about these commands and command qualifiers.

You may identify mount points by one or more of the following methods:

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

16.6 Backing Up a File System

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 without the /IGNORE=INTERLOCK qualifier.

The safest way to back 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.

16.7 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 mount the files in the subdirectory TEST.
3. Enter the following commands:

   $ TCPIP TCPIP> ADD PROXY BROWN /UID=27 /GID=58 /host=ultra TCPIP> MAP DSA301: "/vmsdisk" 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 a name-conversion feature that 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.

See the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual for more options to the ADD EXPORT commmand.

16.8 Setting Up and Exporting a UNIX Style File System

A UNIX style file system is called a container file system. When creating a UNIX style file system, you must name an owner by means of the /USER_NAME qualifier to the CREATE CONTAINER command. 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 be already registered in the proxy database. This user also becomes the owner of the internal root directory of the container.

To create a UNIX style 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 on an OpenVMS volume, assign an owner, and set permissions.
   TCPIP> CREATE CONTAINER DSA101:[TEST] /USER_NAME=SYSTEM /ROOT_MODE=741 /HOST="june"
   This example creates a UNIX style 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 (4)
   • 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 UNIX style 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=741 /HOST="june"
7. Export the root directory or the user top-level directories in the UNIX container.
   

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

   
   or
   

   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 DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

16.9.1 Displaying Directory Listings

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

TCPIP> DIRECTORY "/path/name"

Here, /path/name is a valid UNIX directory specification that begins with a slash (/) and is enclosed by quotation marks.

The DIRECTORY command also has two qualifiers, as follows:

• /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 COPY command to create files in a UNIX style file system because the UNIX directory structure is fully contained in the corresponding container file. Instead, you must use the IMPORT command to copy a file from an OpenVMS directory into a UNIX style file system. Likewise, use the EXPORT command to copy a file from a UNIX style 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.

16.9.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"

16.9.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"

16.9.5 Deleting a UNIX Style 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 UNIX style file system before you delete it.

16.9.6 Verifying the Integrity of a UNIX Style File System

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.

For example, to verify the integrity of a UNIX style file system located in WORK1$:[GROUP_A], enter the following:

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.

You may want to analyze 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 has pointers to the volume and the locations of the actual files on the disk. If you copy the file system, you must run ANALYZE CONTAINER/REPAIR after you copy the files so that the pointers are corrected for the new location of the files.
• During system startup after a system failure.

Table 16-1 lists the important file components of a UNIX style file system that are normally verified by the ANALYZE CONTAINER command.

Table 16-1 UNIX Style 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 DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

16.9.7 Restoring an Entire Container File System

For a typical image restore, follow normal OpenVMS procedures.

For a nonimage restore, an additional step is required after the restore. The Files-11 File IDs are recorded in the container file. These must be updated by the TCPIP ANALYZE CONTAINER /REPAIR command.

This extra step is also required for an image restore if the save set is being restored with the /NOINITIALIZE qualifier to a volume with a different label or if it is being restored to a bound volume set that has a member that was added since the time of the image backup.

16.9.8 Restoring Parts of a Container File System

Before you attempt any of the recovery procedures described in the following sections, you must read and completely understand the following:

1. The procedure you will attempt.
2. Each of the procedures described before it.
3. The OpenVMS documentation for the BACKUP command and qualifiers you will use to produce the intended result.

Sometimes you may need to recover parts of a container file system without losing updates that have been applied to other parts since the backup save set was made. Depending on whether you need to recover files, directories, the container file itself, or some combination, this can be a very awkward and labor-intensive procedure. It can also be error-prone.

16.9.8.1 Using a Temporary Copy of the Container File System

If the container file itself is intact and you have enough free disk space, it may be simplest to restore the entire container file system to a temporary location and then transfer the needed files to the primary copy of the container file system using the TCPIP EXPORT and IMPORT commands. It is also possible to use a remote client if you prefer to allow the users to transfer their own files.

To do this, you can either restore the container file system to a separate disk or to a temporary directory on the same disk. If you use a temporary directory on the same disk, you will need to rename the container file according to the directory name. For example, if the original container file system is in DKA100:[DAISY],

$ DIRECTORY [DAISY]*.CONTAINER DAISY.CONTAINER;1 Total of 1 file. $ TCPIP SHOW MAP /daisy _DKA100:[DAISY] $

If you restore the backup save set to DKA100:[TEMP],

$ RENAME DKA100:[TEMP]DAISY.CONTAINER TEMP.CONTAINER %RENAME-I-RENAMED, DKA100:[TEMP]DAISY.CONTAINER;1 renamed to DKA100:[TEMP]TEMP.CONTAINER;1 $ TCPIP TCPIP> ANALYZE CONTAINER /REPAIR DKA100:[TEMP] . . . TCPIP> MAP "/j2" DKA100:[TEMP]

If you use a remote client to move the files, enter:

TCPIP> ADD EXPORT "/j2" /HOST="robin" TCPIP> EXIT

16.9.8.2 Recovering a Corrupted File That Still Exists

Each of the files in a container file system has two names: the UNIX style name that is recorded in the container file and an OpenVMS name, that you can see using ordinary OpenVMS commands. The OpenVMS names are formed from an eight-digit hexadecimal number prepended to $BFS.;1 or $BFS.DIR;1, depending on whether the file is a directory file. The save set has the files recorded by their OpenVMS names and directory paths: you need to find out what the name and directory are for the particular file you need to recover.

If the file still exists you can do this by entering the DIRECTORY /VMS command. For example,

$ TCPIP DIRECTORY /VMS "/daisy/user1" Directory: /daisy/user1 . VMS file: _DKA100:[DAISY]00003510$BFS.DIR;1 .. VMS file: _DKA100:[DAISY]00012201$BFS.DIR;1 file.txt VMS file: _DKA100:[DAISY.00003510$BFS]00005503$BFS.;1 $

In this example, to recover /daisy/user1/file.txt, you need to select [DAISY.00003510$BFS]00005503$BFS.;1 when you restore.

Note that the hierarchical structure of the directory tree is not reflected in the OpenVMS names of the directory files. All of the OpenVMS directory names are cataloged directly in the container directory [DAISY].

16.9.8.3 Recovering a Deleted File

If the file has been deleted as an OpenVMS file, but its name and attributes are still intact in the container file, the DIRECTORY /VMS command will not show you its former OpenVMS name. You need to compute it.

For each user file and directory file, the container file has the analog of a UNIX inode. In a UNIX file system, each file has an inode in which the file's attributes are stored. Each inode has a unique inode number. The same is true in a container file system.

The inode number is displayed as a decimal number called File ID: when you enter a DIRECTORY /FULL command. For example:

$ TCPIP DIRECTORY /FULL "/daisy/user1/file.txt" Directory: /daisy/user1 login.com VMS file: *** no such file Size File ID: 21763 Blocks: 3 Owner Bytes: 1103 UID: 5107 Created: 23-JUN-1997 10:46:09.10 GID: 15 Revised: 23-JUN-1997 10:46:08.96 Mode: 755 Type: File Accessed: 23-JUN-1997 10:46:08.54 Links: 1 $

To get the OpenVMS name, convert the inode number to hexadecimal. Use enough leading zeros to make eight hexadecimal digits and append $BFS.;1 for a nondirectory file or $BFS.DIR;1 for a directory file. For example, inode number 21763 becomes 00005503$BFS.;1.

You now need to find the OpenVMS name of the immediate parent directory of the file. If the OpenVMS parent directory is still intact, the DIRECTORY /VMS or DIRECTORY /FULL command tells you its OpenVMS name. If the parent directory is not intact, you need to restore the directory by computing the name from the inode number. For example:

$ TCPIP DIR /FULL "/daisy" Directory: /daisy . . . user1 VMS file: _DKA100:[DAISY]00003510$BFS.DIR;1 Size File ID: 13584 Blocks: 4 Owner Bytes: 1915 UID: 5107 Created: 16-JUN-1997 15:46:25.54 GID: 15 Revised: 23-JUN-1997 10:46:08.57 Mode: 741 Type: Directory Accessed: 23-JUN-1997 10:46:08.57 Links: 2 $

In this example, if VMS file: does not show the OpenVMS file name, you must compute it from the inode number, in this case 13584. You need to select [DAISY.00003510$BFS]00005503$BFS.;1 when you restore.

As an alternative method of finding inode numbers, you may find it easier to mount the container file from a UNIX client and use the ls -i and/or ls -R commands. You still need to compute the OpenVMS file specification from the inode numbers of each file to be recovered and its immediate parent directory.