Introduction

Overview

The vast majority of open-systems-compliant systems, now and in the future, will be connected to other systems in local or wide area networks. To exploit the capabilities of these networks, two types of mechanism have been used. In the first traditional model, the existence of the network is explicitly recognised, and interfaces are provided which allow applications or end users to perform operations across the network. In the second, the semantics of local system interfaces are extended to allow access to objects on remote systems, so that applications and end users can (as far as possible) ignore the distinctions between local and remote objects. The first approach is the subject of the X/Open Networking Services Specification (see reference XNS). This document is concerned with the second. More specifically, it is concerned with access to files and directories which are physically stored on remote systems. It does not address operations on, or communications between, processes within a network.

The process of accessing remote files and directories as though they were part of the local file system hierarchy has been termed "transparent file access" (TFA). TFA is an attractive concept for a number of reasons. Using TFA, it becomes possible to use a single set of applications, utilities, and so on, for local and remote operations. For example, instead of invoking a network application such as BSFT (see the X/Open BSFT Specification) to copy a file from one system to another, the XSI cp utility may be used. Accessing a remote file directly, rather than copying it to the local system and working on the copy, has two obvious benefits. First, the single copy of the file can be updated without the need to update the copies. Second, the total disk storage used within the network is reduced. From here it is a short step to using TFA to support a diskless system, in which all file service is networked. Such a system may offer certain benefits in the areas of cost, simplicity and administration.

The most widely used heterogeneous TFA architecture is the Network File System (NFS), originally developed by Sun Microsystems, Inc. NFS has been implemented on a wide range of architectures, from personal computers to mainframes and supercomputers. The specifications for the protocols associated with NFS have been published, and there have been several independent implementations.

With the XNFS specification, The Open Group offers the market a temporary but complete solution to the problem of transparent file access between open-systems-compliant systems. Temporary, because The Open Group recognises the TFA standardisation effort ongoing within the IEEE P1003.1f committee, and The Open Group intends to be compliant with P1003.1f TFA at such time as it becomes an IEEE standard. Complete, because The Open Group now offers both protocols for interoperability (via this XNFS specification) and interfaces for application/user portability (via the XSI specifications, in conjunction with the semantic differences defined in Semantic Difference Summary for File Access , Open-System Interface Semantics over XNFS and Open System Utilities Semantics over XNFS .

There is a certain overlap between the X/Open (PC)NFS Specification and this specification. However, the X/Open (PC)NFS Specification contains a large number of PC-specific definitions, and the two documents address different markets (PC-X/Open Interworking and X/Open-X/Open interworking, respectively).

Scope

This document is a specification for XNFS. XNFS incorporates all of the protocols defined for NFS, and formalises the semantics for XSI applications and utilities operating on remote file systems. A system compliant to an Open Brand for XNFS will be able to access files on any other conforming system, and will be able to make its local files accessible to conforming systems. It will also be able to act as a file server to personal computers running (PC)NFS, as described in the X/Open (PC)NFS Specification. It is intended that it will also be able to interoperate with implementations of NFS on systems which are not compliant with an Open Brand for XNFS, but such interoperation is outside the scope of this specification. Throughout this specification, XNFS will refer to the complete specification, while NFS will refer only to the file-sharing protocol component.

This document contains protocol specifications for External Data Representation (XDR), Remote Procedure Call Protocol (RPC), the Network File System (NFS) and the XNFS adjunct protocols, which include Portmap, Mount, Network Status Monitor (NSM) and Network Lock Manager (NLM). Protocols corresponding to both NFS Version 2 and NFS Version 3 are specified. Systems conforming to this document must support both protocol sets.

This document introduces the WebNFS extensions in an optional appendix.

The RPC specification is included because the NFS protocols are defined in terms of it. The XDR specification is included because the NFS protocols and RPC are defined in terms of it.

The inclusion of these specifications does not mandate the use of distinct XDR or RPC implementation components, nor does it define or mandate any general RPC protocols or interfaces for distributed client/server applications. However, the RPC and XDR specifications define unambiguously the encoding of NFS and adjunct protocol requests and responses when transmitted across a network, as described in RPC Interface to UDP Transport Services .

This specification does not define the utilities and interfaces used for the administration of XNFS. However it is impractical to avoid the issue of configuration entirely. XNFS implementations include a number of configuration options, and many of the semantic issues discussed in the appendices are inherently dependent upon the way in which XNFS is configured. The solution adopted in this document is to define an abstract XNFS Service Model (see XNFS Service Model ) which specifies a set of administrative operations and the attributes of the entities to be managed. The attributes are those defined in the most widely-used NFS reference source from Sun Microsystems, Inc., "NFSSRC4.0". The implementation of the administrative model, in terms of programming interfaces, utilities, data bases and so on, is not specified, and need not be patterned on NFSSRC4.0. It is intended that this specification is compatible and interoperable with current practice as described in RFC 1094 and RFC 1813 (see References to RFCs ). The behaviour described in Semantic Difference Summary for File Access , Open-System Interface Semantics over XNFS and Open System Utilities Semantics over XNFS , is presented in terms of the attributes introduced in the Service Model.

These appendices document the semantic differences experienced when using NFS instead of a local file system.

Audience

There are two intended audiences for this specification. The first includes anyone who wishes to implement XNFS as part of an open-systems-compliant scheme. This specification defines the protocols which are to be implemented by a conforming system, so that it may interoperate with other conforming systems. It does not, however, define the way in which these protocols are to be implemented, nor the way in which XNFS is to be integrated into the rest of the system. If, for example, an implementation performs a read() on a remote file, this specification defines completely the format of the remote request and the corresponding response. It does not define the circumstances under which an implementation should issue a remote read() request. However, as a guide for implementors, a (non-normative) transmission analysis is included as Open Systems Transmission Analysis .

The second audience is the developers of applications. This group relies upon the semantics of the XSI as defined in the X/Open System Interfaces and Headers Specification (see reference XSH) and the X/Open Commands and Utilities Specification (see reference XCU), and needs to be aware of any semantic changes which the use of XNFS may introduce. These changes are described in Semantic Difference Summary for File Access , Open-System Interface Semantics over XNFS and Open System Utilities Semantics over XNFS . Obviously an XNFS implementor must be aware of this material so that his or her implementation does not behave in an unexpected manner.

Terminology

can

implementation-dependent

legacy

may

must

should

With respect to users or applications, the word means recommended programming practice that is necessary for maximum portability.

undefined

unspecified

will

Protocol Stacks and Conformance

An open-systems-conformant XNFS implementation must support the following protocols:

• NFS (see XNFS: Protocol Specification, Version 2 )

• Mount (see Mount Protocol )

• NLM (see Network Lock Manager Protocol )

• NSM (see Network Status Monitor Protocol )

• Portmap (see Port Mapper Protocol ).

• NFS Version 3 (see XNFS: Protocol Specification, Version 3 )

• Mount Version 3 (see Mount Protocol, Version 3 )

• NLM Version 4 (see Network Lock Manager Protocol, Version 4 )

These protocols are defined in terms of the Remote Procedure Call (RPC) protocol, which may employ the External Data Representation (XDR) encoding to ensure operating system independence.

Although the RPC protocol is inherently independent of any particular transport service, an open-systems-conformant NFS implementation must support at least one protocol suite, and support it in the manner defined in this specification.

This specification defines a single transport service, UDP over IP from the Internet Protocol Suite (IPS). All XNFS protocols are implemented over this transport.

Note:

While an implementation may elect to use some other transport such as TCP for communication between XNFS components on a single machine, this is an implementation issue and is not required or described in this specification.

Provided that an interoperable transport service and the same physical connection mechanism are chosen for two systems, conformance to this specification by both system's NFS implementations guarantees that both systems can make their local files accessible for each other and that they can access each other's files.

In addition to the protocols described in the chapters mentioned above, the following chapters are normative for open-systems-compliant NFS implementations:

• XNFS Service Model apart from the MntStdFileSysOp and UnMntAllFileSys operations

• File Locking over XNFS

• Semantic Difference Summary for File Access

• Open-System Interface Semantics over XNFS

• Open System Utilities Semantics over XNFS

Compliance

This specification applies to the X/Open Portability Guide, Issue 3 (XPG3) and the Single UNIX Specification, Issue 4, Version 2 (XCU, XSH and XBD - see Referenced Documents ), except where explicitly stated otherwise.

Relationship to other Open Group Specifications

This specification is based in part on the X/Open (PC)NFS Specification.

The X/Open (PC)NFS Specification defines the protocols for communication between a PC client running DOS or OS/2 and an open-systems-compliant server.

The XNFS specification defines:

• The transparent file access service provided by XNFS

• The protocols that support this service between open-systems-compliant machines, which can take the role of either servers or clients

• The differences in semantics of the X/Open System Interfaces and Headers Specification (see reference XSH) and the X/Open Commands and Utilities Specification (see reference XCU) when they are used "transparently" using XNFS rather than locally

Since many of the protocols used are the same for PC and open-systems-compliant system clients, there is obviously a great deal of overlap between these specifications.

In the event of any inconsistency or disagreement between the two documents, this document is to be treated as authoritative. At some future date, the X/Open (PC)NFS Specification will be revised to include only those elements which are specific to PC clients, such as the pcnfsd protocol, filename and attribute mapping, and the transmission analysis.

This specification describes additional return codes and changed behaviour for some of the system calls and utilities described in the X/Open System Interfaces and Headers Specification (see reference XSH) and the X/Open Commands and Utilities Specification (see reference XCU). These are documented in Semantic Difference Summary for File Access , Open-System Interface Semantics over XNFS and Open System Utilities Semantics over XNFS .

References to RFCs

This document describes only those protocols which have not otherwise been standardised. The RFCs listed in the Referenced Documemts section in the front pages of this document should be consulted for details of the Internet Protocol Suite.

Certain RFC documents are reissued periodically, with each issue receiving a new RFC number. To determine whether a particular RFC is current or not, the reader should consult a copy of the latest RFC Index. Guidance on where to find this information is included in the Referenced Documents section.