This chapter describes how to manage the NFS server. It includes the following topics:
· Server security
· Mounting directories on a client
· Network file locking
· Managing Server parameters
· Maintaining databases
· PCNFSD services and remote printing
· Filename mapping
· Server implementation of NFS protocols
The server provides several features that maintain the integrity of the OpenVMS filesystem.
First, the server requires that the local system must register any user trying to access OpenVMS files. You do this through the PROXY database when you configure the server and through later modifications as needed.
Second, you must export an OpenVMS directory for an NFS user to access it. The server does this through the EXPORT database when you configure the server and through later modifications as needed.
You can take the following additional system security measures:
· Assign an NFS rights identifier to further restrict file access (see the NFS_ACCESS_IDENTIFIER logical under Server Parameters).
· Require all Remote Procedure Call (RPC) requests to originate from privileged ports.
· Restrict all remote mounts to the NFS superuser only.
· Restrict mounts only to explicit directories and not their subdirectories.
· Require the PROXY database to define the mount requester's identification (see the next section).
The PROXY database maps OpenVMS user identification to NFS user identification. NFS user identification is different from that of OpenVMS in that it follows the UNIX model.
OpenVMS identifies users by a username and user identification code (UIC). The UIC consists of a group and a member number. An OpenVMS user can belong to only one group, which can have many members.
NFS follows the UNIX model in identifying users by user ID
(UID) and group ID (GID) numbers. An NFS user can belong to many groups, and
thus have several GIDs. Each NFS request includes the NFS user's effective UID,
GID, or list of GIDs. You can find users' UIDs and GIDs in the
/etc/passwd file
on the UNIX client.
The server uses the PROXY database:
|
When an NFS user requests access to the OpenVMS filesystem |
TCPware maps an NFS user's UID and GID to an OpenVMS username and UIC. The server uses the UIC to check file access permission. |
|
When the NFS client requests file attributes from the server |
The server maps the file owner's UIC to a UID/GID pair. |
|
When a PC requests authentication using PCNFSD |
The server uses the username and password to validate the user, and the UIC to find and return a UID/GID pair. |
The server creates an empty PROXY database during installation. You maintain the PROXY database with the ADD PROXY, CREATE PROXY, REMOVE PROXY, and SHOW PROXY commands in TCPware’s Network Control Utility (NETCU).
A PROXY database entry specifies an OpenVMS username and a corresponding NFS user's UID and GID. The /HOST qualifier with the ADD PROXY command also lets you specify the name of the hosts or hosts where the user account is valid.
The following example shows how to use the ADD PROXY command to assign the SMITH OpenVMS account to an NFS user with a UID=210 and GID=15 on host tulip:
$ NETCU
NETCU>ADD PROXY
SMITH /UID=210 /GID=15 /HOST=TULIP
The PROXY database must contain an entry for each NFS user, including the superuser (see the next subsection).
When you add entries to the PROXY database:
· The OpenVMS username determines file access rights, not the NFS user's UID and GID. The NFS user account has the same access rights as are assigned the OpenVMS account.
· Assign each NFS user the same UID/GID on each NFS client. (See your NFS client documentation for details on global user ID space.)
· Avoid using wildcard UIDs or GIDs. A one-to-one mapping between OpenVMS users and NFS users is easier to maintain.
· Use the /HOST qualifier to allow access only to users from a particular host.
· For PCNFSD users, assign an arbitrary UID and GID for each PC user. Choose a unique UID for each user. Give the same GID to users that need to have group access to each other's files.
The superuser (or root) is a UNIX system user with UID=0 who can perform any operation on a file or process on the client system. However, the superuser cannot automatically access the OpenVMS filesystem on the server. The PROXY database must register a superuser.
The NFS convention is to replace the superuser's UID/GID pair (UID=0, and any GID) with the default values of UID=-2 and GID=-2. By UNIX conventions, this translates to user nobody, which gives the superuser limited access rights. To register a superuser, you must use UID=0 and GID=1, as follows:
NETCU>ADD PROXY DECNET /UID=0 /GID=1
The OpenVMS account to which you assign the superuser access rights determines what rights a superuser has on the OpenVMS system. Superusers require enough access rights so that they can mount directories. (In fact, some server configurations restrict mounting to the superuser). Also, when a user runs a setuid() to root program, the UID/GID in any resulting NFS request has the root UID and, therefore, requires superuser access.
You can create a PROXY entry for a superuser that provides limited access to an OpenVMS filesystem but still allows a superuser to mount exported directories. One example is the DECNET account. Alternately, you can use the OpenVMS AUTHORIZE command to add an account for the superuser on the OpenVMS host.
If you have trusted superusers at particular hosts and wish to give them full privileges on the OpenVMS system, add a separate superuser entry. Assign the superuser to a privileged account (such as SYSTEM) and use the /HOST qualifier to restrict access to a specified host. In the following example, only the superuser on lilac has SYSTEM account privileges:
NETCU>ADD PROXY SYSTEM /UID=0 /GID=1 /HOST=LILAC
The PROXY database is normally static. This means that you have to reload the database every time you use ADD PROXY or REMOVE PROXY to change it. However, you can opt to update the PROXY database dynamically (make it dynamic). You can do so in two ways:
1. Define the TCPWARE_NFS_DYNAMIC_PROXY logical to enable dynamic PROXY database reloading, as follows:
$ DEFINE/SYSTEM/EXEC TCPWARE_NFS_DYNAMIC_PROXY keyword[,keyword]
The keywords are CLIENT, SERVER, NOCLIENT, and NOSERVER, used in any reasonable combination.
Use CLIENT to enable client reloading and SERVER to enable server reloading. However, the /NOCLIENT and /NOSERVER qualifiers used with the ADD PROXY or REMOVE PROXY commands override the logical setting.
2. Use the /CLIENT or /SERVER qualifiers with the ADD PROXY or REMOVE PROXY commands. You can also mix and match by using /CLIENT with /NOSERVER, /NOCLIENT with /SERVER, and so on. Here is an example of its use:
$ NETCU ADD PROXY SMITH /UID=210 /GID=5 /NOCLIENT /NOSERVER
If you disable PROXY database reloading on either the client or server, both methods require the RELOAD PROXY command. RELOAD PROXY is best used if you also specify a username parameter, so that you can reload for a specific username only. Otherwise, it reloads the entire database into memory each time. Therefore, it is best to use RELOAD PROXY at the initial configuration, and only sparingly thereafter.
The EXPORT database contains entries that specify an OpenVMS directory and the host or group of hosts allowed to mount that directory. More than one host can access a directory. The EXPORT database differs from the PROXY database in that the server grants access to a host rather than to a user. If an OpenVMS directory is not in the EXPORT database, an NFS client cannot mount that directory.
An EXPORT database entry specifies a pathname for the OpenVMS directory. Because the OpenVMS device and directory specifications differ from those NFS clients use, the server lets you reference the OpenVMS directory by a UNIX-style pathname. You can assign any pathname to the OpenVMS directory.
|
CAUTION! An authorized user at a remote host can access all subdirectories and files below the export point you specify. Unless you work in a trusted environment, do not export a top level directory, even though it may seem easier to do so. Export only the level of directories that the remote users need, and none higher.
|
The server creates an empty EXPORT database during installation. You maintain the EXPORT database using the ADD EXPORT, CREATE EXPORT, REMOVE EXPORT, RELOAD EXPORT, and SHOW EXPORT commands in NETCU. For example, the following command places an entry in the EXPORT database:
NETCU>ADD EXPORT "/work/notes" $DISK2:[WORK.NOTES]
-
_NETCU>/HOST=(ORCHID,
ROSE)
This command exports the OpenVMS directory $DISK2:[WORK.NOTES] as path
/work/notes to hosts ORCHID and ROSE. The pathname
is an arbitrary one selected to reference the OpenVMS directory. The ADD EXPORT command requires that you enclose the pathname
in quotes.
When a client mounts a subdirectory of an exported directory, each element in the path beyond the exported path must match the corresponding OpenVMS subdirectory name. Separate each element with a slash (/). For example, suppose the NFS client mounts:
$ DISK2:[WORK.NOTES.LETTERS.STUFF]
To match /work/notes, the NFS client uses this path:
/work/notes/letters/stuff
The NFS filename mapping rules apply to the path elements below the export point.
Updating the EXPORT database (using ADD EXPORT or REMOVE EXPORT) usually updates only the server on the host executing the command. You must use either the RELOAD EXPORT command, or restart all the other servers on the cluster to implement changes to the EXPORT database on them.
However, you can automatically reload updates to the shared database on the cluster by setting the TCPWARE_NFS_DYNAMIC_EXPORT logical to CLUSTER, as follows:
$ DEFINE/SYSTEM/EXEC TCPWARE_NFS_DYNAMIC_EXPORT CLUSTER
This causes the server to use locks to communicate changes to all the servers on the cluster. The default for TCPWARE_NFS_DYNAMIC_EXPORT is LOCAL (not to use locks).
The options you can specify while adding entries to the EXPORT database are as follows, using the indicated ADD EXPORT command qualifiers:
·
If you want only specified host or hosts to access the exported
OpenVMS directory, use the
/HOST=[host[,host,...] qualifier.
· Whether or not to enable on-the-fly file conversion: /[NO]CONVERT
·
Whether or not clients can mount subdirectories of a mount point:
/[NO]EXPLICIT_MOUNT
· What kind of filename mapping you want to use: /FILENAME=option
The NFS server includes the UPPERCASE keyword for this qualifier (this does not apply to ODS-5 exports). UPPERCASE changes the default case for exported filenames from lowercase to uppercase, for SRI filename mappings only. The full syntax of the command is
$ NETCU ADD EXPORT /FILENAME=(SRI, UPPERCASE)
Examples of filename conversions are as follows:
|
VMS Name |
Lowercase |
Uppercase |
|
foobar.txt |
foobar.txt |
FOOBAR.TXT |
|
$foobar.txt |
FOOBAR.TXT |
foobar.txt |
|
foo$bar.txt |
fooBAR.TXT |
FOObar.txt |
·
Whether or not you want only the highest version files to appear
in a directory request:
/[NO]HIGHEST_VERSION
·
Whether or not you want incoming requests to originate from a
privileged port:
/[NO]PRIVILEGED_PORT
· Whether or not you want mount requests to originate from a user mapped in the PROXY database: /[NO]PROXY_CHECK
· What kind of record format you want to use for newly created files: /RFM=options
·
Whether or not you want the server (and not just the client) to
perform file access checking:
/[NO]SERVER_ACCESS
·
Whether or not you want only the superuser to mount filesystems:
/[NO]SUPERUSER_MOUNT
· Whether or not the filesystem should be read-only: /[NO]WRITE
NFS clients access OpenVMS files on the NFS server by mounting directories on the client. The MOUNT protocol services the mount request.
Mounting procedures vary by client and may require superuser privileges, or in the case of PC clients, a username and password. Some clients mount a remote directory automatically when they reboot the system (as in the case of fstab). Others mount a remote directory dynamically when they reference the remote file (as with an automount).
Mount procedures require the following information:
· The pathname of the exported directory that matches the pathname in the EXPORT database
· The name of the host running the server that contains the files you want mounted
· A pathname on the client designated as the mount point
Below is an example mount command provided by the TCPware NFS client:
$ NFSMOUNT IRIS "/WORK/RECORDS" NFS0:[USERS.MNT]
In the example, IRIS is the name of the OpenVMS server host. /WORK/RECORDS is the pathname of the exported directory. NFS0:[USERS.MNT] is the mount point on the OpenVMS client host.
Check your NFS client documentation before mounting directories. Mount commands and procedures vary by operating system. Chapter 12, NFS Client Management describes the client mount commands.
The server supports file locking through its implementation of the Network Lock Manager (NLM) and Network Status Monitor (NSM) protocols. Many NFS client systems support file locking, even on the record and byte level, as long as the byte ranges do not overlap. File locking on the server is multi-threaded, where the server can satisfy more than one lock request at a time.
NFS file locking is only advisory. When a client requests a lock on a server file, the goal is for one of its processes to gain exclusive access to this file (or part of the file) and force other processes to wait until the original process releases the lock again. However, the only way NFS denies a client user access to a locked file is if the user also requests a lock on it.
There are two views on network file locking, one from the NFS client's viewpoint and one from the OpenVMS resident user's viewpoint. (See the following sections.)
When an NFS client user requests an advisory lock on a server filesystem, this sends a lockd request to the NLM of the server also running NFSD. This server checks its lock database to see if it can grant the lock. The server cannot grant the lock if:
· Another client has the same file (or region or byte range of the file) already locked.
· An OpenVMS user has the same file open for exclusive access.
· The server waits to reclaim locks during the grace period described below.
The server also includes a Network Status Monitor (NSM). The NSM cooperates with other status monitors on the network to notify the NLM of any changes in system status (such as when a crash occurs).
For example, if the server crashes and comes back up, the server NSM notifies the client NSM that it should resend requests for locks in place before the crash, within a certain grace period (usually 45 seconds). You can request new locks only after this grace period. However, if a client with mounted server files crashes, nobody knows to resend lock requests until the client comes back up again.
To prevent OpenVMS users from accessing files that NFS clients have locked, the server's NLM requests NFSD to open these files for exclusive access. This essentially prevents all access to these files by OpenVMS users. When the client releases the lock by closing the file, the NLM requests NFSD to close the file, at which point OpenVMS users again access it.
If network file locking is to occur in a VMScluster environment, we advise exporting a filesystem from a single node in the cluster only. This way, only a single OpenVMS exclusive lock need occur. Client users can then apply locks on files (or parts of files if enabled) without conflicting with exclusive locks applied from other nodes.
Once you mount a filesystem, the server tries to make the client files recognizable in OpenVMS. Often the filename syntax for NFS files is very different from that of OpenVMS files. For example, NFS filenames do not include file version numbers.
The server translates (maps) filenames from the client so that your OpenVMS host can recognize and use them. Three types of mapping schemes are available:
· Stanford Research Institute (SRI) International mapping, the default scheme between NFS and OpenVMS systems
· PATHWORKS case-insensitive mapping (PATHWORKS)
· PATHWORKS case-sensitive mapping (PATHWORKS_CASE)
Set up the appropriate filename mapping scheme using the /FILENAME qualifier of the ADD EXPORT command in NETCU. If you do not specify the scheme using this qualifier, the server uses the SRI scheme by default.
The below table shows examples of how the server maps NFS directory names and filenames using the SRI mapping scheme. All the client files in the table are NFS files.
For the filename mapping rules, see Appendix A, NFS-to-OpenVMS Filename Mapping.
The filename mapping schemes for the server and the NFS client are identical and totally compatible.
|
Filename on server... |
Is mapped to filename on client... |
|
SERVERFILE.;1 |
serverfile |
|
$C$ASE$S$HIFTED$F$ILE.;1 |
CaseShiftedFile |
|
DOT.FILE$5NTEXT;1 |
dot.file.text |
|
DOT$5NDIRECTORY$5NLIST.DIR;1 |
dot.directory.list (identified as a directory in the UNIX listing) |
|
SPECIAL$5CCHAR$5FFILE.;1 |
special#char&file |
|
DOLLAR$$$S$IGN$$5CFILE.;1 |
dollar$Sign$5cfile |
The server protects an OpenVMS file by comparing its protection information with the user's identification and access rights. It then grants or denies access based on the results of these comparisons.
When an NFS user requests access to an OpenVMS file, the server uses the PROXY database to map the user's user and group identification (UID/GID) on the remote host to a username and UIC on the OpenVMS host. In most cases, this allows the NFS user to have the same access to files as the proxy OpenVMS user.
The NFS client can also do local access checking based on its user and file information and access checking rules before sending the request to the server host. In some cases, this results in the NFS user not having the same access to files as the proxy OpenVMS user.
The following sections explain how the server resolves differences between the two filesystems to provide the best possible mapping between client and server.
The type of access an OpenVMS user has to a file depends how the file and user UICs are related.
OpenVMS has four file ownership categories: SYSTEM, OWNER, GROUP, and WORLD. Each category can have up to four access types: read (R), write (W), execute (E), and delete (D). Each file has a protection mask that defines:
· The categories assigned to the file
· The types of access granted to each category
Here is an example of an OpenVMS protection mask:
SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD=<NO ACCESS>
NFS uses a similar protection scheme as OpenVMS.
Each NFS user has a UID and GID. The file protection categories are: OWNER, GROUP, and OTHER, with the file access types of read (r), write (w) and execute (x). The NFS user's access to a file depends on how the file and owner UIDs/GIDs are related.
The server maps OpenVMS and NFS system protection masks and user identifications so that the relationship between a user and a file remains consistent. For example, if an OpenVMS user owns a particular file and an NFS user is mapped to the account through the PROXY database, the NFS client also considers the local user to be the owner of the file.
|
Note: In OpenVMS, the owner of the file has absolute control over it. This also applies to files remote users create in the mounted filesystem.
|
When the NFS client requests the attributes of a file, the server maps:
· The protection mask to an NFS protection mask
· The owner UIC to a UID/GID
The below table shows how the server maps the protection mask from OpenVMS to NFS.
The server does not map the OpenVMS SYSTEM category and delete (D) access type because they do not exist in the NFS system environment.
The server maps OpenVMS execute (E) to NFS execute (x). However, the OpenVMS system uses the E access type more often than does NFS. Thus, some files might appear to be executable to an NFS host when they are not.
|
OpenVMS category... |
In NFS is... |
With OpenVMS type... |
In NFS is... |
|
SYSTEM |
(not mapped) |
|
|
|
OWNER |
user |
R |
r |
|
|
|
W |
w |
|
|
|
E |
x |
|
|
|
D |
(not mapped) |
|
GROUP |
group |
R |
r |
|
|
|
W |
w |
|
|
|
E |
x |
|
|
|
D |
(not mapped) |
|
WORLD |
other |
R |
r |
|
|
|
W |
w |
|
|
|
E |
x |
|
|
|
D |
(not mapped) |
If the server cannot find the UIC in the PROXY database, or the UID or GID are wildcards, the server returns the default UID or GID.
|
If the file's OWNER UIC... |
Then the Server Returns the... |
|
Matches the requesting NFS user's UIC |
UID/GID of the requester |
|
Group matches the requesting NFS user's UIC group |
GID of the requester and returns the UID from the PROXY database |
|
Does not match the requesting NFS user's UIC |
UID/GID from the PROXY database |
When the NFS client sets or changes the attributes of a file, the server maps the NFS file protection mask to an OpenVMS file protection mask.
The below table shows how the server maps the protection mask from NFS to OpenVMS.
|
NFS category... |
In OpenVMS is... |
With NFS type... |
In OpenVMS is... |
|
user |
OWNER/SYSTEM |
r |
R |
|
|
|
w |
W |
|
|
|
x |
E |
|
|
|
|
D (unless ADF denies) 1 |
|
group |
GROUP |
r |
R |
|
|
|
w |
W |
|
|
|
x |
E |
|
|
|
|
D (unless ADF denies) 1 |
|
other |
WORLD |
r |
R |
|
|
|
w |
W |
|
|
|
x |
E |
|
|
|
|
D (unless ADF denies) 1 |
|
1The server allows delete (D) access only if a special attributes data file (ADF) the server may create (and associates with the file) does not explicitly deny file deletion. |
|||
Access Control List (ACL) file protection is an OpenVMS feature that grants or denies access to a file based on a rights identifier.
If a file has an ACL, the OpenVMS system first uses the ACL for protection checking. If the ACL grants or denies access, OpenVMS goes no further. If the ACL does not grant or deny access, OpenVMS checks the protection mask.
NFS clients using the OpenVMS filesystem may encounter files or directories protected by ACLs. But since the ACLs are unique to the OpenVMS system, the NFS client only checks the protection mask. If the protection mask denies access, the NFS client does not attempt access, even if the file's ACL overrides the protection.
Because the NFS client uses only the protection mask, it is recommended that OpenVMS files protected by ACLs have:
· The ACL set to deny access
· The protection mask set to allow file access
This allows the NFS client to attempt access on the basis of the protection mask, and lets the OpenVMS system control whether access is granted or denied.
When an NFS user creates a file on the OpenVMS host and the directory has an ACL that specifies +DEFAULT, the new file gets the ACL of the directory.
The NFS protocol does not define standard file and record formats or a way of representing different types, such as text or data files. Each operating system can have a unique file structure and record format.
The server provides access to all OpenVMS files. However, even though an NFS client can access a file, the client may not be able to correctly interpret the contents of a file because of the differences in record formats.
The UNIX operating system stores a file as a stream of bytes and uses a line feed (LF) character to mark the end of a text file line. PC systems also store a file as a stream of bytes, but use a carriage-return/line-feed (CRLF) character sequence to mark the end of a text file line. PC systems sometimes also use a Ctrl+Z character to mark the end of a file.
The OpenVMS operating system, with its Record Management Services (RMS), provides many file organizations and record formats. RMS supports sequential, relative, and indexed file organizations. It also supports FIXED, STREAM, STREAM_CR, STREAM_LF, UNDEFINED, VARIABLE, and variable with fixed size control area (VFC) files.
NFS clients most commonly need to share text files. STREAM is the RMS record format that most closely matches PC text files. STREAM_LF is the RMS record format that most closely matches UNIX text files.
In OpenVMS, you can store standard text files in VARIABLE, STREAM_LF, or VFC record format. Most OpenVMS utilities can process these text files regardless of the record format because the utilities access them through RMS.
The intent of the server is to provide convenient access to the majority of OpenVMS files. Because many OpenVMS text files are VARIABLE or VFC format, the server converts these files to STREAM or STREAM_LF format as it reads them.
The server reads all files (except VARIABLE and VFC) block by block without interpreting or converting them. It reads VARIABLE and VFC files by converting them to STREAM or STREAM_LF, based on a selected option. The file on the NFS server remains unchanged.
The server's automatic file conversion process can cause a slow reading of VARIABLE and VFC files. For example, in returning the file size, it reads the entire file. Full directory listings can also be slow if the directory contains a number of VARIABLE or VFC record format files. If you need frequent access to these files, consider converting them using the OpenVMS CONVERT utilities described in Converting Files Manually.
See the NFS_DIRREAD_LIMIT parameter in Advanced Parameters.
By default, the server creates STREAM_LF files, but can also create STREAM files on demand. It writes all files except VARIABLE and VFC block by block without interpreting or converting them. If an NFS client tries to write to or change the size of an existing file not having STREAM, STREAM_LF, STREAM_CR, FIXED, or UNDEFINED format, the server returns an EINVAL error.
You can improve server performance by manually converting files using the OpenVMS CONVERT utilities described in this section.
Variable to STREAM_LF
Use this conversion procedure to make a variable-length file available to a UNIX system client without using the server's automatic conversion feature. To convert a variable-length record file to STREAM_LF, the command format is:
$ CONVERT/FDL=TCPWARE:STREAMLF source-file destination-file
The source-file specification is the variable-length record file. The destination-file specification is the name of the new file to contain the STREAM_LF records.
STREAM_LF to Variable
Use this conversion procedure to make a file created by a UNIX system client available to an OpenVMS application that does not understand the STREAM_LF record format. To convert a STREAM_LF file to variable-length, the command format is:
$ CONVERT/FDL=TCPWARE:VMSTEXT source-file destination-file
The source-file specification is the STREAM_LF file. The destination-file specification is the name of the new file to contain the variable-length records.
Variable to STREAM
Use this conversion procedure to make an OpenVMS variable-length file available to a PC client. Keep in mind that the server's automatic conversion procedure uses LF characters, not CRLF character sequences, for record terminators.
To convert a variable-length record file to STREAM format (with CRLF line terminators), the command format is:
$ CONVERT/FDL=TCPWARE:STREAMCRLF source-file destination-file
The source-file specification is the variable-length record file. The destination-file specification is the name of the new file to contain the STREAM records.
|
Note: The variable-to-stream conversion does not add a Ctrl+Z to the end of the file. If a PC application requires the Ctrl+Z, use the conversion program the NFS client software provides.
|
TCPware provides several basic parameters you can adjust to better suit your needs. To change the value of any of these parameters, invoke the network configuration command procedure (CNFNET) by entering the following command:
$ @TCPWARE:CNFNET NFS
The server also provides advanced parameters that you rarely need to change but appear here for reference purposes only.
The default parameter values appear in parentheses following the parameter name. All parameters are logicals and are static. When you make a change to a parameter, you must stop and restart the server for the change to take effect. TCPware uses logical names (the parameter names prefixed by TCPWARE_) to communicate the parameters to the NFS server. The STARTNET procedure defines these logicals.
The basic parameters described here are in the same order in which the server prompts you to provide values for them during the NFS configuration procedure. The default setting for each parameter appears in parentheses.
|
NFS_ACCESS_IDENTIFIER (null) |
Specifies the name of a rights identifier you want assigned to all NFS users. You can then modify the access control lists (ACLs) of files to grant or deny access to holders of the rights identifier. The default is null (no rights identifier).
OpenVMS files protected by ACLs should have the UIC-based protection mask set to allow file access and the ACL set to deny access. This lets the NFS client access on the basis of the protection mask, and lets the OpenVMS system control whether to grant or deny access. |
|
NFS_SECURITY (0) |
Enables various security features. This parameter is a bit mask value (in decimal) as defined in the NFS_SECURITY Bit Mask Values table below.
The following global parameters supersede the values set using the corresponding qualifiers of the ADD EXPORT command, if applicable, as indicated in the NFS_SECURITY Bit Mask Values table below. |
|
NFS_LOG_CLASS (-1) |
Enables the type of information written to the log file TCPWARE:NFSSERVER.LOG This parameter is a bit mask value (in decimal), as defined in the NFS_LOG_CLASS Bit Mask Values table below. |
NFS_SECURITY bit mask values:
|
Bit No. |
Mask |
Meaning When Set |
Supersedes Qualifier for ADD EXPORT |
|
0 |
1 |
Superuser mount enabled. Restricts remote mounts of the OpenVMS filesystem to the superuser UID (UID=0) |
/[NO]SUPERUSER |
|
1 |
2 |
Explicit mount enabled. You can only mount directories (and not their subdirectories) in the EXPORT database. |
/[NO]EXPLICIT_MOUNT |
|
2 |
4 |
Mount PROXY check. The UID and GID specified in all mount requests must exist in the PROXY database. |
/[NO]PROXY_CHECK |
|
3 |
8 |
Privileged port check. Requires that all incoming NFS requests originate from privileged ports on the client. Privileged ports are port numbers less than 1024. |
/[NO]PRIVILEGED_PORT |
|
4 |
16 |
Access checks for all files to the client performed by server only. The server reports mode 777 (octal). This allows full use of OpenVMS ACLs used to grant or deny file access. One implication is that the client reports an access mode of rwxrwxrwx for all files. |
/[NO]SERVER_ACCESS |
|
(remaining) |
|
Reserved for future use. |
|
You cannot disable fatal errors and the server writes them to OPCOM. The default (-1) is all classes of information enabled.
NFS_LOG_CLASS bit mask values:
|
Bit... |
Means when set... |
Which are... |
|
1 |
Warnings |
Error recovery messages |
|
2 |
MOUNT requests |
MOUNT call messages |
|
4 |
General |
General operation messages |
|
8 |
Security |
Security violation messages |
|
16 |
NFS errors |
NFSERR_IO messages |
|
(remaining) |
|
Reserved for future use |
|
Description |
|
|
NFS_DFLT_UID (-2), NFS_DFLT_GID (-2) |
Specifies the default UID and GID. The server uses these defaults in the following cases: · The server receives a request from a user without a PROXY mapping and who is also the superuser (UID=0, and any GID). The server replaces the superuser UID and GID with the default UID and GID. · The server processes a get attributes request and cannot find a file's owner UIC in the PROXY database. The server uses the default UID and GID instead. |
|
NFS_DIRLIFE_TIMER (:3) |
Sets when to delete internal directory cache data structures. The server periodically scans these data structures and deletes them if a directory's cache has existed for longer than the NFS_DIRLIFE_TIMER value. This preserves memory. Specify the interval as OpenVMS delta time. The default is 3 minutes.
If you are unfamiliar with delta time, see Chapter 13, NFS Client Management, Client Commands. |
|
NFS_DIRREAD_LIMIT (-1) |
Sets the maximum size in bytes for each file read while processing a get attributes request. If the estimated file size exceeds this value, TCPware does not read the file to determine its exact size and returns an estimated size instead. The estimated file size is always larger than the exact size. The -1 default effectively turns off file size estimation.
This parameter applies only to filesystems exported with the /CONVERT option (the default). A value of 0 disables TCPware from determining exact file sizes on requests.
This parameter may provide the NFS client with inexact file sizes. This is generally not a problem, but may affect some applications. |
|
NFS_DIRTIME_TIMER (::30) |
Sets a time interval that determines when the server updates the directory access time between NFS operations. Specify the interval as an OpenVMS delta time. The default is 30 seconds. |
|
NFS_FILE_CACHE_SIZE (1024) |
Determines the maximum number of files allowed to have attributes in cache at any one time. The number must be larger than the SYSGEN parameter CHANNELCNT. The value must also be larger than the number of combined TCP and UDP threads (see the NFS_TCP_THREADS and NFS_UDP_THREADS parameters). |
|
NFS_NOCHECKSUM (0) |
Enables or disables checksum generation for UDP datagrams. This parameter is a Boolean value. When the value is 0 (false), the server generates checksums for outgoing datagrams. When the value is 1 (true), the server does not generate checksums. Enabling checksums maintains data integrity, and is the default.
Note: Disabling checksums may increase system performance but could have an adverse effect on certain NFS clients. |
|
NFS_OPENFILE_TIMER (::6) |
Sets a time interval (in delta time) a file remains open after you last accessed it. This can speed up request processing since a file can remain open for successive read or write requests. You do not need to open and close it for each request. The default is six seconds. You should not leave a file open for extended time, nor leave it open for too short an interval, which can decrease performance. |
You should not normally change the parameters described in this section. If you need to change a value for an advanced parameter, edit the TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM file.
The advanced parameters that follow appear in alphabetical order. The default setting for each parameter is in parentheses.
This section describes the server restrictions and implementation of the Network File System (NFS) protocol. The material presented here requires a thorough understanding of the protocols. It does not explain or describe the protocols.
The server has the following OpenVMS-related restrictions:
· The server supports Files-11 ODS-2 structure level disks, ODS-5 formatted disks, and any CD-ROM format.
· The server does not implement volume protection. All exported devices should be public devices.
· The server does not generate security or audit alarms. However, the server writes access violations to log file TCPWARE:NFSSERVER.LOG (as long as you enable security logging through the NFS_LOG_CLASS parameter).
· When creating files and directories, the server sets the owner UIC of the file or directory to the UIC derived from the UID/GID in the create request authentication information or to the UID/GID in the set attributes information (if available).
The server implements the following NFSv3 protocol procedures (while continuing to support NFSv2):
|
Procedures |
Description |
|
ACCESS (access) NFSv3 only
|
The server determines the access rights that a user, as identified by the credentials in the request, has with respect to a file system object. |
|
COMMIT CACHED WRITE DATA (commit) NFSv3 only |
The server forces data to stable storage that was previously written with an asynchronous write call. |
|
CREATE FILE (create) |
The server creates files using the record format specified in the EXPORT database entry. The client may specify one of 3 methods to create the file: · UNCHECKED: File is created without checking for the existence of a duplicate file. · GUARDED: Checks for the presence of a duplicate and fails the request if a duplicate exists. · EXCLUSIVE: Follows exclusive creation semantics, using a verifier to ensure exclusive creation of the target. |
|
GET ATTRIBUTES (getattr) |
Gets a file's attributes. The server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: · File protection - The server maps the OpenVMS file protection mask to the UNIX file protection mask. · Number of links - Although OpenVMS supports hard links, it does not maintain a reference count. Therefore, the server sets this value to 1 for regular files and 2 for directory files. · UID/GID - The server maps a file owner's UIC to a UID/GID pair through the PROXY database. · Device number - The server returns the device number as -1. · Bytes used - The total number of bytes used by the file. · Filesystem ID - The server returns the filesystem ID as 0. · Access, modify, status change times - The OpenVMS system does not maintain the same file times as NFS requires. The server returns the OpenVMS revision (modify) time for all three NFS times.
For directory files, the server returns the access, status change, and modify times as a reasonably recent time, based on the time of the last server-initiated directory change, and the NFS_DIRTIME_TIMER parameter. This is a benefit to clients that cache directory entries based on the directory times.
OpenVMS bases its time on local time, while UNIX bases its time on Universal time (or Greenwich mean time), and these times may not agree. The offset from Universal time specified when configuring TCPware resolves the difference between local and Universal time. |
|
GET DYNAMIC FILESYSTEM INFO (fsstat) NFSv3 only |
The server provides volatile information about a filesystem, including: · total size and free space (in bytes) · total number of files and free slots · estimate of time between file system modifications |
|
GET FILESYSTEM STATISTICS (statfs) NFSv2 only |
Returns filesystem statistics. The server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: Block size—The block size is 1024. Total number of blocks—The total number of blocks is the SYS$GETDVI MAXBLOCK parameter divided by 2. Blocks free—The number of blocks free is the SYS$GETDVI FREEBLOCK parameter divided by 2. Blocks available—The number of blocks available to unprivileged users is the same as the number of blocks free. |
|
GET STATIC FILESYSTEM INFO (fsinfo) NFSv3 only |
The server provides nonvolatile information about a filesystem, including: · preferred and maximum read transfer sizes · preferred and maximum write transfer sizes · flags for support of hard links and symbolic links · preferred transfer size of readdir replies · server time granularity · whether or not times can be set in a settaddr request |
|
LINK (link) |
Creates a hard link to a file. The server stores the link count in an application access control entry (ACE) on the file. |
|
LOOKUP FILE (lookup) |
Looks up a file name. If the file name does not have a file extension, the server first searches for a directory with the specified name. If the server fails to locate a directory, it searches for the file name without an extension. |
|
MAKE DIRECTORY (mkdir) |
Creates a directory. The OpenVMS system does not allow the remote host to create more than eight directory levels from the root of the OpenVMS filesystem. The server ignores access and modify times in the request. |
|
READ DIRECTORY (readdir) |
Reads a directory. The server returns file names using the filename mapping scheme as specified in the EXPORT database entry. The server also drops the VMS version number from the file name for the highest version of the file. |
|
READ DIRECTORY PLUS ATTRIBUTES (readdirplus) NFSv3 only |
In addition to file names, the server returns file handles and attributes in an extended directory list. |
|
READ FROM FILE (read) |
Reads from a file. The server converts VARIABLE and VFC files to STREAM or STREAM_LF format (depending on the option set) as it reads them. The server returns EOF when detected. |
|
REMOVE DIRECTORY (rmdir) |
Deletes a directory. |
|
REMOVE FILE (remove) |
Deletes a file. |
|
RENAME FILE (rename) |
Renames a file. If the destination filename is the same as an existing filename and the destination filename does not have a zero or negative version number, the server overwrites the existing file. |
|
READ LINK (readlink) |
Reads the contents of a symbolic link. |
|
SET ATTRIBUTES (setattr) |
Sets file attributes. The server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: · File protection - The server maps the UNIX file protection mask to the OpenVMS file protection mask, as shown earlier in this chapter. · UID/GID - The client changes the file owner's UIC. The PROXY database maps the new UID/GID to an OpenVMS UIC. If the server cannot locate the new UID/GID in the database, it returns an error and does not change the owner UIC. · Size - If the file size is larger than the allocated size, the server extends the file. If the size is 0, the server truncates the file and sets the record attributes to sequential STREAM_LF. You cannot change the size of variable length or VFC files (except to zero). · Access time - Changing the access time has no effect on the OpenVMS system. · Modify time - The modify time updates the OpenVMS revision time. |
|
SYMBOLIC LINK (symlink) |
Creates a symbolic link. The server creates the file with an undefined record structure and uses an application ACE on the file to mask it as a symbolic link. |
|
WRITE TO FILE (write) |
Writes to a file. The server does not allow a remote host to write to a directory file, or to VARIABLE and VFC files.
If the server allowed a remote host to write to an existing OpenVMS file that was not a STREAM_LF or fixed-length record format file, the file could become corrupted. The server does not allow a remote host to explicitly change the record format of an OpenVMS file.
The server can return the non-standard NFS error ETXTBSY (26) and EINVAL (22). The server returns ETXTBSY when an OpenVMS user has a file open for exclusive access and an NFS user tries to use the file in a way that is inconsistent with the way the OpenVMS user opened the file. The server returns EINVAL if an NFS user tries to write to or change the size of a VARIABLE or VFC record format file.
With Version 3, the server supports asynchronous writes (see COMMIT). |
If you are experiencing network communication-related problems on the NFS server, please check the following items:
1. Make sure TCPware is running on the OpenVMS system.
2. Make sure the server is running. If not, start it by entering the following command at the DCL prompt:
$ @TCPWARE:STARTNET NFS
If the server is not running but was started, examine the TCPWARE:NFSSERVER.LOG file. This file contains information to help you isolate problems with the server. After correcting any problems that were reported in the log file, restart the server.
3. To verify general connectivity between the two systems, try using FTP or TELNET. For example, try to open a TELNET connection with the remote host in question. If FTP or TELNET are not available on your system, try using the TCPware PING utility.
4. Verify the internet addresses the local host and the remote hosts are using. If your local network includes a gateway, also verify the gateway address.
If you are experiencing problems performing NFS operations from a NFS client, check the server's TCPWARE:NFSSERVER.LOG file. It may contain messages that can help isolate the problem. A new NFSSERVER.LOG file may be created by typing NETCU SET LOG/NEW/NFS.
Certain messages can also come up with the NETCU SHOW EXPORT, SHOW MOUNT, and UNMOUNT commands.
Access error messages help by entering HELP TCPWARE MESSAGES.