Network file system (NFS)

The Network File System (NFS) provides access to and from systems that have NFS implementations.

NFS is an industry-standard method for sharing information among users on networked systems. Most major operating systems, including PC operating systems, provide NFS. For UNIX systems, NFS is the primary method for accessing data. System i® product can act as both an NFS client and an NFS server.

When you are the security administrator of an IBM® i platform that acts as an NFS server, you need to understand and manage the security aspects of NFS. Suggestions and considerations:

You must explicitly start the NFS server function by using the STRNFSSVR command. Control who has authority to use this command.
You make a directory or an object available to NFS clients by exporting it. Therefore, you have very specific control over which parts of your system you will make available to NFS clients in your network.
When you export, you can specify which clients have access to the objects. You identify a client by system name or IP address. A client can be an individual PC or an entire System i product or UNIX system. In NFS terminology, the client's IP address is called a machine.
When you export, you can specify read-only access or read/write access for each machine that has access to an exported directory or object. In most cases, you will probably want to provide read-only access.
The NFS does not provide password protection. It is designed and intended for data sharing within a trusted community of systems. When a user requests access, the server receives the user’s user identification number (uid). Some uid considerations are:
- The System i product attempts to locate a user profile with the same uid. If it finds a matching uid, it uses the credentials of the user profile. Credentials is an NFS term to describe using the authority of a user. This is similar to profile exchanging in other IBM i applications.
- When you export a directory or object, you can specify whether you will allow access by a profile with root authority. The NFS server on System i products equates root authority to *ALLOBJ special authority. If you specify that you will not allow root authority, an NFS user with a uid that maps to a user profile with *ALLOBJ special authority will not be able to access the object under that profile. Instead, if anonymous access is allowed, the requester will be mapped to the anonymous profile.
- When you export a directory or object, you can specify whether you will allow anonymous requests. An anonymous request is a request with a uid that does not match any uid on your system. If you choose to allow anonymous requests, the system maps the anonymous user to the IBM-supplied QNFSANON user profile. This user profile does not have any special authorities or explicit authority. On the export, you can specify a different user profile for anonymous requests if you want.
When your system participates in an NFS network, or any network with UNIX systems that depend on uids, you probably need to manage your own uids instead of letting the system assign them automatically. You will need to coordinate uids with other systems in your network.
You might discover that you need to change uids, even for IBM-supplied user profiles, to have compatibility with other systems in your network. A program is available to make it simpler to change the uid for a user profile. When you change the uid for a user profile, you also need to change the uid for all the objects that the profile owns in either the root directory or the QOpenSrv directory. The QSYCHGID program automatically changes the uid in both the user profile and all the owned objects.