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

22.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.

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

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

22.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.

22.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 22-2 lists the components of a container file system that are normally verified by the ANALYZE CONTAINER command.

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

22.10.7 Restoring a 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 identifiers are recorded in the container file. These must be updated by the TCP/IP management command ANALYZE CONTAINER /REPAIR.

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.

22.11 Setting Up NFS Security Controls

The NFS server and the OpenVMS operating system provide many levels of security controls you can use to protect your file systems. Section 22.1.3, Section 22.1.4, and Section 22.1.7 describe how the server uses the proxy and export databases to restrict client access, and how to use OpenVMS account privileges and file protections to control access to files and directories.

The NFS server provides additional security controls through the use of the noproxy_enabled attribute. You can set this attribute in the NFS server site-specific startup file SYS$STARTUP:TCPIP$NFS_SERVER_SYSTARTUP.COM.

The server uses this attribute while it is running. If the attribute is set, a proxy is not required for users attempting to access the NFS server. For more information about the NFS server attributes, see Table 22-3.

22.12 Modifying NFS Server Attributes

You can modify the way the NFS server works by specifying NFS server attributes using the SYSCONFIG command. The characteristics of the NFS server that you can modify include:

• Proxy security
• Default proxy UID
• Default proxy GID
• Maximum concurrent TCP threads
• Maximum concurrent UDP threads

To make permanent modifications:

1. If it does not already exist, create the file SYS$STARTUP:TCPIP$NFS_SERVER_SYSTARTUP.COM.
2. Include the SYSCONFIG command to set the variables. For example:

   $ SYSCONFIG -r nfs tcp_threads=20 udp_threads=40

3. Shut down and then restart the NFS server to make the changes take effect. For example:

   $ @SYS$STARTUP:TCPIP$NFS_SERVER_SHUTDOWN.COM $ @SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM

Future upgrades or installations will not overwrite the definitions in the TCPIP$NFS_SERVER_SYSTARTUP.COM file.

Modifying NFS server characteristics can affect NFS server performance. Be sure you understand the impact (review Section 22.15) before making any changes.

Table 22-3 describes the NFS server attributes that you can modify to affect NFS server performance.

Table 22-3 Modifying NFS Server Attributes

Attribute	Description
noproxy_enabled	Enables the use of the noproxy_uid and noproxy_gid attributes. If this attribute is not set to 1, proxies are required for server access. If the value is 0, files owned by a user that is not in the proxy database are assumed to be owned by UID=-2/GID=-2. If the value is 1, files owned by a user not in the proxy database are reported to be owned by the values of the noproxy_uid and noproxy_gid attributes.
noproxy_uid	Specifies the default UID when a user cannot be translated by the proxy.
noproxy_gid	Specifies the default GID when a user cannot be translated by the proxy.
tcp_threads	Specifies the number of concurrent TCP threads within the server. A value of zero will disable the TCP protocol.
udp_threads	Specifies the number of concurrent UDP threads within the server. This value must not be zero.
vnode_age	Specifies the number of seconds in the time interval since the last file access request. The server keeps an activity timestamp for each opened file to help manage the open file cache. You can also modify this value with the /INACTIVITY qualifier to the SET NFS_SERVER command. The default setting for this variable is 120, or 2 minutes. Be careful not to set this value to a small interval; this might reduce performance.
ovms_xqp_plus_enabled	Controls the way the NFS server accesses the directory cache. For more information, see Section 22.15.3.

22.13 Modifying File System Characteristics

The file SYS$STARTUP:TCPIP$NFS_STARTUP.COM contains definitions of logical names that set the file system parameters. To change the settings of these logical names, define them in the SYS$STARTUP:TCPIP$SYSTARTUP.COM command procedure by using the /EXECUTIVE_MODE and /SYSTEM qualifiers.

Table 22-4 describes these logical names.

Table 22-4 File System Logical Names

Logical Name	Description
TCPIP$CFS_CACHE_LOW_LIMIT	Defines the minimum size of the free buffer list. When the list is smaller than the value of this logical name, the file system starts to reclaim used buffers. The default is 4 buffers. The free buffer list needs at least 4 free buffers (not taken by cache). If the actual number of free buffers is less than TCPIP$CFS_CACHE_LOW_LIMIT, the used buffers are returned to the free list until the size of the free list reaches the value of TCPIP$CFS_CACHE_HIGH_LIMIT.
TCPIP$CFS_CACHE_HIGH_LIMIT	Defines the number of buffers the file system tries to keep in the free buffer list. The default is 8 buffers. See TCPIP$CFS_CACHE_LOW_LIMIT. In a busy server environment, setting this parameter higher is likely to improve performance.
TCPIP$CFS_CACHE_SIZE	Defines the maximum number of cache buffers to be allocated.
TCPIP$CFS_NAME_CACHE_SIZE	Establishes the size of the file name cache. For more information, see Section 22.15.3.
TCPIP$CFS_ODS_CACHE_SIZE	Establishes the size of the ODS cache. For more information, see Section 22.15.3.
TCPIP$CFS_PREFER_VERSION	Controls whether the number after a dot in a file name is interpreted as a file extension or a version number. By default, a dot followed by a number is assumed to be a file extension. When this logical name is set, the number is assumed to be a version number. This logical name applies to ODS-5 volumes using typeless directories.
TCPIP$CFS_TRANSFERSIZE	Defines the optimum size (in bytes) of the data transferred between server and client on READ and WRITE operations. The default is 8K bytes (8192 bytes). This value is used in most NFS server implementations.
TCPIP$CFS_SHOW_VERSION	Sets the SHOW_VERSION logical name ON or OFF. If ON, the NFS server returns to the client file names with version numbers, even if there is only one version of the file. The default is OFF.
TCPIP$CFS_MODUS_OPERANDI	Defines various operating modes. Use only under the advice of your HP support representative.
TCPIP$CFS_FATAL_MESSAGES	Defines the terminal device to which the important error messages are directed, in addition to the normal error messages that are sent to the operator's console. The default is _OPA0:.

22.14 File Locking

TCP/IP Services supports a partial implementation of NFS network locking, which allows users to lock files. The software coordinates locks among remote users and between remote and local users. The file locking features is applicable regardless of whether the OpenVMS Record Management Services (RMS) is used. However, NFS does not coordinate network locking and RMS record locks.

File locking is implemented using the Network Lock Manager (NLM) (also known remote procedure call, or RPC, lockd ) and the Network Status Monitor (NSM) (also known as RPC statd ). The NLM coordinates locks made by clients. The NSM recovers lock information in case the server or client fails. The NSM uses the NLM to keep the host list when the client or the server fails and reboots, as follows:

• If the client fails and reboots, it notifies the NSMs on its host list. In turn, the NSMs tell their local NLMs to free any locks held for that client.
• If the server fails, when it reboots it notifies the NSMs on each client host in its host list. In turn, the client NSMs tell their local NLMs to request again all the locks that were granted on their behalf by the server before it failed.

The NSM and the NLM are enabled if you select LOCKD/STATD in the TCPIP$CONFIG.COM configuration procedure. As a result, two processes are started when you start TCP/IP Services: TCPIP$LOCKD and TCPIP$STATD. The NLM can be configured with the following optional parameters:

• TCPIP$LOCKD_TIMEOUT_PERIOD specifies the timeout period (in seconds). This value defines the amount of time for the client to wait before retransmitting a lock request to which the server has not responded. The default setting is 5 seconds.
• TCPIP$LOCKD_GRACE_PERIOD specifies the grace period (in seconds). This value defines the amount of time the NLM will deny new lock requests after a failure while the NSM is recovering the lock status. The default setting is 15 seconds.

To set these parameters, create or edit the following file:

SYS$STARTUP:TCPIP$LOCKD_SYSTARTUP.COM