AS/400e IBM OS/400 Network File System Support Version 4 SC41-5714-01
AS/400e IBM OS/400 Network File System Support Version 4 SC41-5714-01
Note Before using this information and the product it supports, be sure to read the information in “Notices” on page 99. Second Edition (May 1999) This edition replaces SC41-5714-00. © Copyright International Business Machines Corporation 1997, 1999. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Tables ix . . . . . . . . . . . . . . . . . . . . . . . . . . . About OS/400 Network File System Who should read this book . . . . AS/400 Operations Navigator . . . Installing Operations Navigator. . Prerequisite and related information . How to send your comments . . . Summary of Changes Support (SC41-5714) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5. Client Mounting of File Systems . . . . . What Is Mounting? . . . . . . . . . . . . . . . Why Should I Mount File Systems? . . . . . . . . . What File Systems Can I Mount? . . . . . . . . . . Where Can I Mount File Systems? . . . . . . . . . Mount Points . . . . . . . . . . . . . . . . How Do I Mount File Systems? . . . . . . . . . . ADDMFS (Add Mounted File System) Command . . . RMVMFS (Remove Mounted File System) Command . DSPMFSINF (Display Mounted File System Information) . . . . . . . . . .
Network Data Encryption . . User Authorities . . . . . . User Identifications (UIDs) . Group Identifications (GIDs) . Mapping User Identifications Proper UID Mapping . . . Securely Exporting File Systems Export Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi OS/400 Network File System Support V4R4
Figures 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. AS/400 Operations Navigator Display . . . . . . . . . . . . . The local client and its view of the remote server before exporting data . The local client and its view of the remote server after exporting data . The local client mounts data from a remote server . . . . . . . .
54. 55. 56. 57. 58. viii Using the End NFS Server (ENDNFSSVR) display . . . . . Starting or stopping NFS server daemons. . . . . . . . . NFS Properties dialog box. . . . . . . . . . . . . . . Using the Release File System Locks (RLSIFSLCK) display . . Client outside the trusted community causing a security breaches OS/400 Network File System Support V4R4 . . . . . . . . . . . . . . . . . . . .
Tables 1. CL Commands Used in Network File System Applications . . . . . . . 91 © Copyright IBM Corp.
x OS/400 Network File System Support V4R4
About OS/400 Network File System Support (SC41-5714) The purpose of this book is to explain what the Network File System is, what it does, and how it works on AS/400. The book shows real-world examples of how you can use NFS to create a secure, useful integrated file system network. The intended audiences for this book are: v System administrators developing a distributed network using the Network File System.
Figure 1. AS/400 Operations Navigator Display This new interface has been designed to make you more productive and is the only user interface to new, advanced features of OS/400. Therefore, IBM recommends that you use AS/400 Operations Navigator, which has online help to guide you. While this interface is being developed, you may still need to use a traditional emulator such as PC5250 to do some of your tasks.
http://www.as400.ibm.com/infocenter http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm The AS/400 Information Center contains important topics such as logical partitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also contains Internet links to Web sites such as the AS/400 Online Library and the AS/400 Technical Studio.
xiv OS/400 Network File System Support V4R4
Summary of Changes This manual includes changes made since Version 4 Release 1 of the OS/400 licensed program on the AS/400 system. This edition includes information that has been added to the system to support Version 4 Release 4. Changes made to this book include the following items: v Updated graphic files. v Updated examples. v Updated NFS to FSS/400 comparisons. v Added information about short and long names. v Added a new section about editing files within the /etc directory. © Copyright IBM Corp.
xvi OS/400 Network File System Support V4R4
Chapter 1. What is the Network File System? Introduction OS/400 Network File System Support introduces a system function for AS/400 that aids users and administrators who work with network applications and file systems. You can use the Network File System (NFS**) to construct a distributed network system where all users can access the data they need. Furthermore, the Network File System provides a method of transmitting data in a client/server relationship.
Figure 3. The local client and its view of the remote server after exporting data After the server exports information, the proper client (the client with the proper authorities) can be aware of the existence of file systems on the server. Furthermore, the client can mount the exported file systems or directories or objects from the server. Figure 4. The local client mounts data from a remote server The mount command makes a certain file system, directory, or object accessible on the client.
OS/400 Network File System Support is the replacement for the TCP/IP File Server Support/400 (FSS/400) system application. Users who are accustomed to working with FSS/400 will notice many similarities between FSS/400 and NFS. It is important to note, however, that FSS/400 and NFS are not compatible with each other. The FSS/400 system application can exist on the same AS/400 with OS/400 Network File System Support, but they cannot operate together.
users that all data exists and is processed on their local workstations. An efficient NFS network also gives the right people access to the right amount of data at the right times. Files and directories can be made available to clients by exporting from the server and mounting on clients through a pervasive NFS client/server relationship. An NFS client can also, at the same time, function as an NFS server, just as an NFS server can function as a client.
Each group of users works on sets of clients that need different file systems from the TULAB server. Each group of users has different permissions and authorities and will pose a challenge to establishing a safe, secure NFS namespace. Chris Admin will encounter common problems that administrators of NFS namespaces face every day. Chris Admin will also work through some uncommon and unique NFS situations.
6 OS/400 Network File System Support V4R4
Chapter 2. The Network File System Client/Server Model To understand how the Network File System works on AS/400, you must first understand the communication relationship between a server and various clients. The client/server model involves a local host (the client) that makes a procedure call that is usually processed on a different, remote network system (the server). To the client, the procedure appears to be a local one, even though another system processes the request.
A daemon is a process that performs continuous or system-wide functions, such as network control. NFS uses many different types of daemons to complete user requests. A cache is a type of high-speed buffer storage that contains frequently accessed instructions and data. Caches are used to reduce the access time for this information. Caching is the act of writing data to a cache. For information about NFS server daemons, see “Network File System Server-Side Daemons” on page 9.
Representation (XDR) and then sent to the server using a socket. The simple User Datagram Packet (UDP) protocol actually communicates between client and server. Some aspects of NFS use the Transmission Control Protocol (TCP) as the base communication protocol. The operation of NFS can be seen as a logical client-to-server communications system that specifically supports network applications. The typical NFS flow includes the following steps: 1. The server waits for requests from one or more clients. 2.
Figure 9. The NFS Server NFS is similar to other RPC-based services in its use of server-side daemons to process incoming requests. NFS may also use multiple copies of some daemons to improve overall performance and efficiency. RPC Binder Daemon (RPCD) This daemon is analogous to the port mapper daemon, which many implementations of NFS use in UNIX. Clients determine the port of a specified RPC service by using the RPC Binder Daemon.
Network Status Monitor Daemon (NSMD) The Network Status Monitor (NSM) is a stateful NFS service that provides applications with information about the status of network hosts. The Network Lock Manager (NLM) daemon heavily uses the NSM to track hosts that have established locks as well as hosts that maintain such locks. There is a single NSM server per host. It keeps track of the state of clients and notifies any interested party when this state changes (usually after recovery from a crash).
v Mount and Unmount commands. Users can mount and unmount a file system in the client namespace with these commands. These are general tools, used not only in NFS, but also to dynamically mount and unmount other local file systems. For more information about the ADDMFS (Add Mounted File System) and RMVMFS (Remove Mounted File System) commands, see “Chapter 5. Client Mounting of File Systems” on page 39. Network File System Client-Side Daemons Figure 10.
Client-side caching in NFS reduces the number of RPC requests sent to the server. The NFS client can cache data, which can be read out of local memory instead of from a remote disk. The caching scheme available for use depends on the file system being accessed. Some caching schemes are prohibited because they cannot guarantee the integrity and consistency of data that multiple clients simultaneously change and update.
Data Cache The data cache is very similar to the directory and file attribute cache in that it stores frequently used information locally on the client. The data cache, however, stores data that is frequently or likely to be used instead of file or directory attributes. The data cache provides data in cases where the client would have to access the server to retrieve information that has already been read. This operation improves the performance of NFS.
Chapter 3. NFS and the User-Defined File System (UDFS) | | | | A user-defined file system (UDFS) is a type of file system that you directly manage through the end user interface. This contrasts with a system-defined file system (SDFS), which AS/400 system code creates. QDLS, QSYS.LIB, and QOPT are all examples of SDFSs. | | | | | The UDFS introduces a concept on AS/400 that allows you to create and manage your own file systems on a particular user Auxiliary Storage Pool (ASP).
CRTUDFS Display Create User-Defined FS (CRTUDFS) Type choices, press Enter. User-defined file system . . . . > '/DEV/QASP02/kate.udfs' Public authority for data . . . *INDIR Name, *INDIR, *RWX, *RW... Public authority for object . . *INDIR *INDIR, *NONE, *ALL... + for more values Auditing value for objects . . . *SYSVAL *SYSVAL, *NONE, *USRPRF... Additional Parameters Case sensitivity . . . . . . . . Text 'description' . . . . . . .
This command creates a case sensitive user-defined file system (UDFS) named kate.udfs in the user Auxiliary Storage Pool (ASP), qasp02. Display a User-Defined File System The Display User-Defined File System (DSPUDFS) command presents the attributes of an existing UDFS, whether mounted or unmounted. DSPUDFS Display Display User-Defined FS (DSPUDFS) Type choices, press Enter. User-defined file system . . . . Output . . . . . . . . . . . . . /DEV/QASP02/kate.
Display User-Defined FS User-defined file system . . . : /DEV/QASP02/kate.udfs Owner . . . . . . Code page . . . . Case sensitivity . Creation date/time Change date/time . Path where mounted PATRICK 37 *MIXED 02/26/96 08:00:00 08/30/96 12:30:42 Not mounted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : Description . . . . . . . . . : Press Enter to continue. Bottom F3=Exit F12=Cancel (C) COPYRIGHT IBM CORP. 1980, 1996. Figure 13.
DLTUDFS Display Delete User-Defined FS (DLTUDFS) Type choices, press Enter. User-defined file system . . . . > '/DEV/QASP02/kate.udfs' F3=Exit F4=Prompt F24=More keys F5=Refresh F12=Cancel Bottom F13=How to use this display Figure 14. Using the Delete User-Defined FS (DLTUDFS) display When you use the DLTUDFS command, you only have to specify one parameter: v The UDFS parameter determines the name of the unmounted UDFS to delete. This entry must be of the form /DEV/QASPXX/name.
| | 2. Export the path to the UDFS mount point (the directory you mounted over in Step 1) | | | | The previous steps will ensure that the remote view of the namespace is the same as the local view. Afterwards, the exported UDFS file system can be mounted (Type *NFS) by remote NFS clients. However, you must have previously mounted it on the local namespace. ADDMFS/MOUNT Display For a display of the ADDMFS (Add Mounted File System) and MOUNT commands, please see “RMVMFS/UNMOUNT Display” on page 49.
Saving and Restoring a User-Defined File System The user has the ability to save and restore all UDFS objects, as well as their associated authorities. The Save command (SAV) allows a user to save objects in a UDFS while the Restore command (RST) allows a user to restore UDFS objects. Both commands will function whether the UDFS is mounted or unmounted. Graphical User Interface A Graphical User Interface (GUI) provides easy and convenient access to UDFSs.
Figure 16. A Windows 95 view of using the DSPUDFS (Display UDFS) command This window displays the properties of a user-defined file system. For more information about the DSPUDFS command, see “Display a User-Defined File System” on page 17. User-Defined File System Functions in the Network File System | | | | To export the contents of a UDFS, you must first mount it on the local namespace. Once the Block Special File (*BLKFS) mounts, it behaves like the ″root″ or QOpenSys file systems.
| | | directories. For this reason, exporting /DEV or objects within it can cause administrative difficulties. The next sections describe how you can work around one such scenario. Using User-Defined File Systems with Auxiliary Storage Pools This scenario involves an eager user, a non-communicative system administrator, and a solution to an ASP problem through the Network File System. A user, Jeff, accesses and works with the TULAB2 namespace each time he logs into his account on a remote NFS client.
EXPORTFS OPTIONS('-I -O ROOT=TUclient52X') DIR('/DEV') 2. Now the client can mount the exported directory and place it over a convenient directory on the client, like /tmp. MOUNT TYPE(*NFS) MFS('TULAB2:/DEV') MNTOVRDIR('/tmp') 3. If the client uses the WRKLNK command on the mounted file system, then the client can now access the false ASP directory and connecting directories will be maintained. WRKLNK '/tmp/*' 4.
Chapter 4. Server Exporting of File Systems A key feature of the Network File System is its ability to make various local file systems, directories, and objects available to remote clients through the export command. Exporting is the first major step in setting up a “transparent” relationship between client and server. Before exporting from the server, remote clients cannot “see” or access a given file system on the local server.
Figure 18. Dynamically exporting file systems with the ″-I″ option The mount daemon checks the export table each time a client makes a request to mount an exported file system. Users with the proper authority can update the /etc/exports file to export file systems at will by adding, deleting, or changing entries. Then the user can use the export command to update the export table.
Chris Admin can export a directory containing only the database files with statistics of the bridge construction safety records. This operation can be performed without fear of unknown users accessing the sensitive data. Chris Admin can use the export command to allow only selected client systems to have access to the files. This way, both groups of students will be able to mount and access the same data and work with it on their separate, different workstations.
Figure 20. After the server has exported /classes/class2 After exporting, a remote client can view the exported file systems PROJ2 and PROJ3. Not all the file systems on the server are visible to remote clients. Only the exported file systems are available for mounting by clients with proper authorities as specified on the export command or in the /etc/exports file. Remote clients can not see anything except for their own local files and those that the various remote servers have exported.
Figure 21. A directory tree before exporting on TULAB2 On any given server file system, when you start exporting, all the objects beneath the export point will also be exported. This includes directories, files, and objects. For example, if you export /classes from TULAB2, then everything below Figure 22. The exported directory branch /classes on TULAB2 /classes is also exported, including /classes/class1, /classes/class2 and their associated sub-directories.
For example, the file system /home/sweet/home has been exported, and /home/sweet is a parent directory of /home/sweet/home. You cannot now export /home/sweet unless it exists on a different local file system. 4. You can only export local file systems. Any file systems or proper subsets of file systems that exist on remote systems cannot be exported except by those remote systems. For example, /help exists on a different server than the one you are currently accessing.
You can export to specific groups of clients by using the /etc/netgroup file. This file contains an alias for a group of clients to whom file systems will be exported. No other systems outside of the netgroup will be able to access the file systems. For more information about the /etc/netgroup file, see “/etc/netgroup File” on page 96.
v The directory entry is the name of the directory that you want to export. The pathname you specify will be listed in the DIR parameter on the CHGNFSEXP command. This entry specifies the path name of the existing directory to be exported (made available to NFS clients) or unexported (made unavailable to NFS clients). This directory can not be a sub-directory or a parent of an already exported directory (unless it is in a different file system).
CHGNFSEXP OPTIONS('-I -O RO,ANON=199,ACCESS=Prof:1.234.5.6') DIR('/engdata/mech') HOSTOPT((TULAB1 850 850)) This command exports the directory tree under the path name /engdata/mech as read-only. This command allows only two clients to mount this directory tree. It takes advantage of the positional parameters, which do not require keywords. It uses the HOSTOPT parameter to specify code pages for the host TULAB1. Example 3: Exporting a directory to many netgroups.
Figure 25. The Operations Navigator interface. 3. Choose NFS –> Properties to bring up the dialog box that is shown below. | | Figure 26. The NFS Export dialog box.
| | | | | 4. Customize the export on a per-client basis under the Access tab. 5. Set the public access rights as desired. 6. Click on the Add Host/Netgroup button. This will allow you to add other clients with specific privileges. The figure below shows a display of the dialog box. Figure 27. The Add Host/Netgroup dialog box. | | | | 7. Click OK to add your selected clients. This will bring you back to the NFS Exports dialog, where your selected clients are now in the list. 8.
Figure 28. The Customize NFS Clients Access dialog box. In the Exports dialog, clicking the Export button will immediately export the folder on the AS/400 server. You also have the option of updating the /ETC/EXPORTS file with this new or changed export. | | | | Finding out what is exported | | Often, you need to know the items that are currently exported on an AS/400 system. There are three ways to do this: | | | 1. Through Operations Navigator. 2.
| | | | 5. Select Exports. From here, you can easily add new exports or remove entries from the list. The figure below shows the dialog box for NFS Exports. Figure 29. The NFS Exports dialog box. | Retrieve Network File System Export Entries (QZNFRTVE) API | | | | | A second method of finding currently exported items on an AS/400 is using the Retrieve Network File System Export Entries (QZNFRTVE) API.
| Exporting Considerations Mounted File System Loops Users and administrators can encounter difficulty with the inability of NFS to export an already-mounted Network File System. NFS will not allow the export of a mounted file system because of the possibility of mounted file system loops. This problem would occur if NFS allowed the mount and then new clients mounted the namespace. The new clients would then discover that to find the mount point, they would have to pass through the mount point.
Chapter 5. Client Mounting of File Systems The mount command places the remote file system over a local directory on an NFS client. After exporting, mounting a file system is the second major step in setting up a “transparent” relationship between client and server. Mounting allows clients to actually make use of the various file systems that the server has exported. Clients can use the mount command to map an exported file system over all or just part of a local file system.
Figure 31. A local client mounting file systems from a remote server Given the proper authority, an NFS client can mount any file system, or part of a file Figure 32. The mounted file systems cover local client directories system, that has been exported from an NFS server. Mounting is the local client action of selecting an exported directory from a remote server and making it accessible to the integrated file system namespace of the local client.
Figure 33. The local client mounts over a high-level directory There is a “downstream” principle for mounting that is similar to the “downstream” rule for exporting. Whenever you mount a remote file system over a local directory, all of the objects “downstream” of the mount point are “covered up”. This renders them inaccessible to the local namespace. If you mount at a high level of a local directory tree, then you will cause most of your objects to become inaccessible. Figure 34.
Sometimes the namespace of a client can become too complicated or overwhelmed with information. The unmount command is an easy way to slowly disengage from the server one file system at a time. To unmount all file systems, specify the *ALL value for the TYPE parameter on the UNMOUNT or RMVMFS (Remove Mounted File System) commands.
For example, TULAB2 exports /classes/class1, which contains the directory /classes/class1/proj1. A remote client has a local directory /user, which contains the directory /user/work, which contains the directory /user/work/time. The client mounts /classes/class1/ over /user/work, which causes the mounted file system to completely cover up everything on the local directory tree that is “downstream” from the mount point. The mount point is /user/work. The /user/work directory now contains only proj1.
The new local directory tree on the client will display /user/work and the various contents and sub-directories, as shown here. Figure 38. The remote server exports /engdata Figure 39. The local client mounts /engdata over a mount point Figure 40. The /engdata directory covers /user/work Note: NFS clients will always see the most recent view of a file system. If the client dynamically mounts or unmounts a file system, the change will be reflected on the namespace of the client after the next refresh.
Mount Points Mount points mark the area of the local client and remote server namespaces where users have mounted exported file systems. Mount points show where the file system has been mounted from on the server and show where it is mounted to on the client. | | | | | | | For example, the system exports the /home/consults directory from TULAB1 and mounts it over the /test directory on a remote client. The mount point on the client is /test.
2. If you are mounting a user-defined file system or a Network File System, then you require *R (read) authority to the file system being mounted. 3. If you are mounting a NetWare file system, then you require *X (execute) authority to the file system being mounted. 4. You must have *W (write) authority to the directory being mounted over. For more information about the ADDMFS and MOUNT commands and the associated parameters and options, see CL Reference, SC41-4722.
v The path name code page specifies what code page should be assumed for path names on the remote system. This is a code page to be assumed for path names on the remote system. Any AS/400 code page is supported on this parameter. Graphical User Interface Figure 42. A Windows 95 view of Mounting a user-defined file system | | When accessing AS/400 through AS/400 Client Access, you can dynamically mount user-defined file systems by using the Windows 95 graphical user interface (GUI).
ADDMFS TYPE(*NFS) MFS('TULAB2:/QSYS.LIB/WORK.LIB') MNTOVRDIR('/HOME') OPTIONS('ro, nosuid, rsize=256, retrans=10') CODEPAGE(*JOBCCSID) This command mounts the /qsys.lib/work.lib file system from the remote system TULAB2 onto the local client directory /HOME. This command also specifies: v Mount as read-only v Disallow setuid execution v Set the read buffer to 256 bytes v Set the retransmission attempts to 10 The default job CCSID is used to determine the code page of the data on the remote system.
2. a remote file system accessed via a Network File System server (*NFS) 3. a local or remote NetWare file system (*NETWARE). If any of the objects in the file system are in use, the command will return an error message to the user. Note that if any part of the file system has itself been mounted over, then this file system cannot be unmounted until it is uncovered. If multiple file systems are mounted over the same mount point, the last to be mounted will be the first to be removed.
Examples Example 1: Unmounting a Directory. RMVMFS TYPE (*NFS) MNTOVRDIR('/tools') This command unmounts a Network File System that is accessible on directory /tools. Example 2: Unmounting a User-Defined File System. RMVMFS TYPE(*UDFS) MFS('/DEV/QASP02/A.udfs') This command unmounts the user-defined file system /DEV/QASP02/A.udfs. Example 3: Unmounting all mounted file systems on a client. RMVMFS TYPE(*ALL) MNTOVRDIR(*ALL) This command unmounts all the file systems that a client has mounted.
Display Mounted FS Information (DSPMFSINF) Type choices, press Enter. Object . . . . . . . . . . . . . /dev/qasp02/kate.udfs Output . . . . . . . . . . . . . * F3=Exit F4=Prompt F24=More keys F5=Refresh F12=Cancel *, *PRINT Bottom F13=How to use this display Figure 44.
Display Mounted FS Information Object . . . . . . . . . . . . : /home/students/ann File system type . . . . . . . : User-defined file system Block size . . . . . . . . Total blocks . . . . . . . Blocks free . . . . . . . Object link maximum . . . Directory link maximum . . Pathname component maximum Path name maximum . . . . Change owner restricted . No truncation . . . . . . Case Sensitivity . . . . . 4096 2881536 1016026 32767 32767 510 No maximum Yes Yes No . . . . . . . . . . . . . . . . . . . .
Examples Example 1: Displaying Statistics of a Mounted File System. DSPMFSINF OBJ('/home/students/ann') This command displays the statistics for the mounted file system that contains /home/students/ann. Example 2: Displaying ’/QSYS.LIB’ File System Statistics. DSPMFSINF OBJ('/QSYS.LIB/MYLIB.LIB/MYFILE.FILE') This command displays the statistics for the /QSYS.LIB file system that contains *FILE object MYFILE in library MYLIB. Chapter 5.
54 OS/400 Network File System Support V4R4
Chapter 6. Using the Network File System with AS/400 File Systems | | | | | | There are several exceptions to using AS/400 file systems with NFS on various clients. This is because you are able to export several different file systems on an AS/400 NFS server. Each file system has its own set of requirements and deviations through NFS from its normal functioning state. The purpose of this chapter is to make you aware of these differences for the specific file system you are accessing through NFS.
Network File System Differences Case-Sensitivity When a remote UNIX client mounts an object that the server exports from the “root” (/) file system, it will always function as case-insensitive. Read/Write Options No matter what options the client specifies on the MOUNT command, some server file systems from “root” (/) exist as only read-write. However the client mounts a file system determines how the file system is treated and how it functions on the client.
Read/Write Options No matter what options the client specifies on the MOUNT command, some server file systems from QOpenSys exist as read-only or read-write. However the client mounts a file system determines how the file system is treated and how it functions on the client. Library File System (QSYS.LIB) Figure 49. The QSYS.LIB file system accessed through the NFS Server Network File System Differences Exporting and QSYS.LIB You can export some .LIB and .FILE objects. If you export .
Note: See the System API Reference, SC41-4801 book for more details on the open() API and the O_TEXTDATA and O_CODEPAGE options. QPWFSERVER Authorization List The QPWFSERVER is an authorization list (object type *AUTL) that provides additional access requirements for all objects in the QSYS.LIB file system being accessed through remote clients. The authorities specified in this authorization list apply to all objects within the QSYS.LIB file system.
from 92, which leaves a default of 80 bytes per record for source physical files. For any record length specified, the real amount of bytes per record is the number specified minus 12 bytes for source physical files. Byte-Range Locks QSYS.LIB does not support byte-range locking. The fcntl() API will fail with error condition ENOSYS if used by clients. Case-Sensitivity QSYS.LIB is case-insensitive. UNIX clients are typically case-sensitive.
Document Library Services File System (QDLS) Figure 50. The QDLS file system accessed through the NFS Server Network File System Differences Mounting and QDLS Users can mount the QDLS file system on a client, but users cannot mount over the QDLS file system. File Creation Users cannot create regular files in the top-level /QDLS directory. Users can only create files in the sub-directories of /QDLS.
| | | using the ADDDIRE (Add Directory Entry) command. All anonymous client requests that are mapped to QNFSANON will fail at the server if you do not enroll the QNFSANON user profile in FMS. For more information regarding the QDLS file system, see v Integrated File System Introduction, SC41-4711 v Managing OfficeVision/400, SH21-0699 v Office Services Concepts and Programmers Guide, SH21-0703 Optical File System (QOPT) Figure 51.
Case-Sensitivity | QOPT is case-insensitive. It converts lowercase English alphabetic characters to uppercase when used in object names. Therefore, the path name /QOPT/volume/dir/file represents the same path as /QOPT/VOLUME/DIR/FILE.. Security and Authorization The QOPT file system offers volume-level security, as opposed to file or directory-level security. Each optical volume is secured by an authorization list.
Network File System Differences Case-Sensitivity When remote UNIX clients mount objects that the server exports from a UDFS, the case-sensitivity is variable, depending on how the user created the UDFS. A UDFS that is mounted on a UNIX client can cause the case-sensitivity to change in the middle of a directory tree. System and User Auxiliary Storage Pools The contents of a UDFS exist in a user auxiliary storage pool (ASP), but the UDFS block special file itself always lies in the system ASP.
64 OS/400 Network File System Support V4R4
Chapter 7. NFS Startup, Shutdown, and Recovery NFS startup performs separately and independently on each machine. The startup of an NFS component on one system does not trigger the startup of an NFS component on another system. For example, if you start the Network Lock Manager on a client, the NLM on the server will not automatically start up. For proper functioning of NFS, there is an implied order in which the daemons should be started on any given system or network.
| | | | | | a. Select option 2 (Change) from the CFGTCP menu to add a name for an address. b. Select option 1 from the CFGTCP menu to add an entire new address with names. 6. Verify that the names LOOPBACK and LOCALHOST are associated with the IP address 127.0.0.1 in the host table. | | | | 7. Verify that the long and short names of each NFS server you need access to are included in the host table. You only need to do this if you will be using the system as an NFS client.
waits for requests (the standard is #2049). All server daemons will use this same port. The NFS server daemons then wait on the port for RPC requests from NFS clients to access local files. 4. The user starts the mount daemon (QNFSMNTD). This daemon registers to the local RPC binder daemon. It then waits on the assigned port for RPC requests from NFS clients to mount local file systems. 5. The user starts the NSM daemon (QNFSNSMD). It registers to the local RPC binder daemon.
If you attempt to start a daemon or daemons that are already running, they will not cause the command to fail, and it will continue to start other daemons you have requested to start. The command will issue diagnostic message CPDA1BA if the daemon is already running. For best results, end NFS daemons before attempting the STRNFSSVR command.
STRNFSSVR Display Start NFS Server (STRNFSSVR) Type choices, press Enter. Server daemon . . . . . . . Number of server daemons . . Number of block I/O daemons Timeout for start of daemon F3=Exit F4=Prompt F24=More keys . . . . . > *ALL . 1 . 1 . *NOMAX F5=Refresh *ALL, *RPC, *BIO, *SVR... 1-20 server daemons 1-20 server daemons 1-3600 seconds F12=Cancel Bottom F13=How to use this display Figure 53.
This command starts the NFS mount daemon, and waits up to the default of 30 seconds for it to start. The mount daemon should not be already running, and other daemons have been started in the appropriate order. Proper Shutdown Scenario Shutting down an NFS server properly allows for all jobs to finish and all requests to be completed. In general, the order of actions required for the server to shutdown are the exact opposite of actions required for the server to startup: 1.
v v v v The The The The mount (MNT) daemon server (SVR) daemon block I/O (BIO) daemon Remote Procedure Call (RPC) binder daemon If you are choosing to end just one daemon, be sure you understand the appropriate order for ending NFS daemons and the possible consequences of ending deamons in an order other than that specified above. If you attempt to end a daemon or daemons that are not running, they will not cause the command to fail, and it will continue to end other daemons you have requested to end.
v The required SERVER parameter on the ENDNFWSVR command specifies the Network File System daemon jobs to end. v The ENDJOBTIMO parameter on the ENDNFSSVR command specifies the number of seconds to wait for each daemon to successfully end. If a daemon has not ended within the timeout value, the command will fail. Examples Example 1: End All Daemons ENDNFSSVR SERVER(*ALL) This command ends all NFS daemon jobs that are running.
Figure 55. Starting or stopping NFS server daemons. | | You can also display the status of each individual daemon by choosing Properties. This brings up the following dialog box: | Figure 56. NFS Properties dialog box. | | In the example, Chris Admin has decided to start 4 of the Server type daemons to give better throughput. You can start up to 20 of these daemons from the General Chapter 7.
| | | | tab of the previous dialog box. Notice that the Network lock manager daemon is stopped. This could indicate that it encountered a problem by trying to start up. Alternately, it could mean that the administrator chose to end it specifically because of no need for byte range locking. | | | | Both NFS and RPC share the same Remote Procedure Call Binder daemon. Starting or stopping NFS will start or stop RPC, and vice versa.
If a client with a granted lock request should happen to fail, a specific set of operations will occur at startup time to recover the locks: 1. When the user restarts the NSM daemon on a system, the daemon will send a change of state RPC to other NSM daemons in the network. This message is transmitted only to the other NSM daemons that the failed system is aware of in the network. 2. After receiving a change of state from a remote system, the NSM uses RPC to communicate with the local NLM.
RLSIFSLCK Display Release File System Locks (RLSIFSLCK) Type choices, press Enter. Remote location . . . . . . . . TULAB2 Object . . . . . . . . . . . . . F3=Exit F4=Prompt F24=More keys F5=Refresh F12=Cancel Bottom F13=How to use this display Figure 57.
Chapter 8. Integrated File System APIs and the Network File System Error Conditions There are two error conditions that commonly appear when working with the Network File System through integrated file system APIs (application program interface) that require special consideration. These error conditions are the ESTALE and EACCES error conditions. ESTALE Error Condition The return of this error number means that the server has rejected the file or object handle.
UDP does not guarantee the delivery or order of data returned to clients. A client may receive any one of the following return codes for a successful operation: 1. Return code=0 (RC=0). The operation is completed successfully. 2. EEXIST. The operation is completed successfully. This error condition was returned to the client because the return code of 0 (RC=0) was either lost or received out of order. 3. ENOENT. The operation is completed successfully.
Once a file or directory is open, subsequent requests to perform operations on a file or directory can fail. This is because attributes are checked at the server on each request. When permissions on the object are more restrictive at the server, your operations on an open file descriptor will fail when NFS receives updates. When the server unlinks the object or makes it unavailable, then your operations on an open file descriptor will fail when NFS receives updates.
80 OS/400 Network File System Support V4R4
Chapter 9. Network File System Security Considerations You can use the Network File System to create a seamless, transparent namespace where all users have access to the right information at any given time. However, NFS also has special security considerations. These considerations deal mainly with user, group, and supplemental user identifications. This chapter discusses these concerns along with certain parameters and options of the CHGNFSEXP command.
Network Data Encryption Figure 58. Client outside the trusted community causing a security breaches A client existing outside the trusted community can become aware of the community’s existence. Furthermore, a malignant client can introduce a “sniff” program that can read and change data as it transfers in the client/server relationship. It accomplishes this by intercepting the data flow and altering the data on contact. The system sends unencrypted data as plain text between the client and server.
User Authorities As users log on to NFS clients and servers, the user authority of each user dictates what they can and cannot do. User authorities are assigned to users by administrators, and usually take the form of user identifications (UIDs) for particular users, group identifications (GIDs) for groups of users, and supplemental GIDs, which list various group identifications that a user belongs to.
forbidden to their profiles. It is important to become aware of which users from which groups have access to your data. GIDs can help a user from a powerful group gain unauthorized access to sensitive data. | | | The various IDs a user has and the attached authorities can create NFS security hazards. This is particularly crucial when dealing with the CHGNFSEXP command options for making file system available to clients.
appropriate to both the user and the system in question. Just because users need *SECOFR authority on one system does not mean that they need that same authority on all machines. UID Mapping Examples In the TULAB, an engineering graduate student named Bill has a UID of 136 on TULAB1 and a UID of 142 on AS/400 TULAB2. If Bill wants to mount or otherwise access a file on TULAB1, his UID of 136 will be transmitted to that server.
There are other ways to tap into a system of users and the objects owned by them. The administrator of a client can deliberately impersonate a remote server UID. For example, the administrator of a client can log on and access the UID of a user, Mary on TULAB2, who accesses the client. If the UID of Mary is 123, then the client administrator can assume this UID and, in effect, become Mary on both systems. There exists on TULAB2 a file named /home/mary/index.html.
However, instead of changing the UID and user profile for each user on each system, administrators can use the QSYCHGID API (application programming interface). This new API can be called from AS/400 command lines, C programs, COBOL programs, and through other interfaces as well. This function can change the UIDs and GIDs of both system-provided profiles and regular user profiles. To use this command, an administrator must include the following entries: 1. A ten-character profile name.
1. Administrators should never export the “root” (/) Directory. Remember that whenever you export a file system, you also export all of the directories and objects “downstream” of the path. Should the “root” (/) directory become exported, all the other directories and objects downstream of “root” (/) will become exported as well. Export only what is needed by clients. 2. Administrators should never export any file system to “the world,” allowing universal client access to information.
v Change the file permissions for “the world” while still mapped to QNFSANON Exporting to ″The World″ Instead of making exported data accessible to everyone, an administrator can employ the technique of specifying selective clients. Administrators can use the ACCESS option of the CHGNFSEXP command to use this technique. This option will also accept particular UIDs, GIDs, and supplemental GIDs. Using the ACCESS option limits access to exported files to only the specified clients.
90 OS/400 Network File System Support V4R4
Appendix A. Summary of Common Commands Table 1. CL Commands Used in Network File System Applications Command Description ADDMFS Add Mounted File System. Places exported, remote server file systems over local client directories. CHGNFSEXP Change Network File System Export. Adds or removes directory trees to the export table of file systems that are exported to NFS clients. CRTUDFS Create UDFS. Creates a User-Defined File System. DLTUDFS Delete UDFS. Deletes a User-Defined File System.
92 OS/400 Network File System Support V4R4
Appendix B. Understanding the /etc Files A directory named /etc exists within the integrated file system namespace. This directory contains important system files that users should never write to or change unless they are experienced NFS administrators. NFS uses these files to perform specific system functions.
In the EDTF utility, you find all the appropriate line commands by pressing the F1 (Help) Function Key. | | | Editing stream files by using a PC based editor | | | | | The second method to edit the netgroup file is by using a PC-based editor. If you want to use a PC-based editor, you need access to the /etc directory on the AS/400. Use one of the following to accomplish this: | | If you are using Operations Navigator, you must have direct access to the /etc directory.
10. No tabs or line feeds can be used in the path name 11. All characters following the pound sign ’#’ are considered comments until the end of the line. The only exception to this rule is the HOSTOPT parameter, which uses the ’#’ character as a starting point for each HOSTOPT entry. Formatting the HOSTOPT (Host Options) Parameter In /etc/exports, you can provide additional information for each export entry related to the remote NFS clients who will access your entry.
3. Options are case-insensitive. 4. Options that are not specified will be processed as the defaults described in “Formatting the HOSTOPT (Host Options) Parameter” on page 95. Examples of Formatting /etc/exports with HOSTOPT Parameter Example 1: Exporting to a host and specifying all options. /home/joe access=sammy #HOSTOPT HostName=sammy, PathNameCodePage=367, DataFileCodePage=850, NoWaitForWrites \ \ \ \ A user exports /home/joe to host sammy, specifying code pages for both path names and data files.
host-name The name of any host from the /etc/hosts file. AS/400 does not support the /etc/hosts file as a separate integrated file system file. The /etc/hosts is built in to AS/400 TCP/IP support. user-name The name of any user from the /etc/passwd file. AS/400 does not support the /etc/passwd file concept. domain-name The name of any domain. On AS/400, the following format rules apply to netgroups: 1. All entries are ended by the end of a line. 2.
98 OS/400 Network File System Support V4R4
Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used.
Software Interoperability Coordinator 3605 Highway 52 N Rochester, MN 55901-7829 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us.
Programming Interface Information This publication is intended to help you to use OS/400 Network File System Support to construct a distributed network. This publication documents General-Use Programming Interface and Associated Guidance Information provided by OS/400 Network File System Support. General-Use programming interfaces allow the customer to write programs that obtain the services of OS/400 Network File System Support.
102 OS/400 Network File System Support V4R4
Bibliography This bibliography lists publications that contain background information or more details for information that OS/400 Network File System Support discusses. The list below gives the full title and order number of each book. OS/400 Network File System Support may use a shortened version of the title when referring to these books. If you want more information on a topic while you are using this bibliography, see the Publications Reference, SC41-4003, for related AS/400 publications.
104 OS/400 Network File System Support V4R4
Index Special Characters /etc/exports file 95 description 94 formatting entries 94 HOSTOPT parameter 95 HOSTOPT parameter format rules purpose 94 /etc files 93, 94, 95 /etc/exports file 94 description 94 formatting entries 94, 95 purpose 94 /etc/netgroup file 96, 97 description 96 format rules 97 purpose 96 /etc/pmap file 97 description 97 purpose 97 /etc/statd file 97 description 97 purpose 97 description 93 export command /etc/exports 93 /etc/netgroup 93 file creation 93 introduction 93 /etc/netgroup file
caches 14, 14 (continued) definition 14 directory and file attribute cache description 13 functions 13 introduction 12 case-sensitivity 16, 17 /etc/netgroup file 97 CASE parameter 16 create a UDFS 15 create a udfs case-insensitive 16 case-sensitive 17 CRTUDFS command 15, 16 CRTUDFS display 16 pattern-matching 59 QSYS.
DSPMFSINF command description 50 display 50 examples 53 OBJ parameter 51 purpose 50 DSPUDFS command UDFS parameter 17 E encryption definition of types 82 introduction 82 ENDNFSSVR command 72 display 71 ENDJOBTIMO parameter 71 purpose 70 restrictions 71 SERVER parameter 71 error conditions additional error numbers 77 Error Conditions EACCES error condition 77 error conditions EEXIST error condition 77 ENOENT error condition 77 Error Conditions ESTALE error condition 77 EXPORTFS restrictions 31 EXPORTFS comm
file systems 61, 15, 55, 56, 57, 58, 59, 60, 61mdit (continued) root (/) file system case-sensitivity 56 Network File System differences 55 read/write options 56 user-defined file system (UDFS) auxiliary storage pools (ASPs) 63 case-sensitivity 63 Network File System differences 62 what you can export 27 what you can mount 45 where you can mount 42 FSS/400 introduction 3 description 3 G GIDs definition 83 introduction 83 K Kerberos authorization 83 definition 83 encryption 83 M monitored locks definition
Network File System 74, 9, 10, 11, 12, 13, 14, 65, 66mdit (continued) byte-range locks (continued) statelessness 74 why should I lock a file? 74 caches definition 8 client 8, 11, 77 block I/O daemon (BIOD) 12 caches 12 contents 11 daemons 12 data cache 14 directory and file attribute cache 13 client/server communication 7 client/server model 7 client/server relationship 7 daemons definition 8 description 3 encoding 8 exporting file systems 25 integrated file system 77 introduction 1 mounting file systems 39
P protocols 9, 77 NFS 4, 8 single-threaded 9 NFS protocol 77 RPC 4, 8 stateless 4 TCP 4, 8, 70 UDP 4, 8, 70 considerations 77 XDR 8 Q QDLS file system 60 Network File System differences 60 anonymous users 60 file creation 60 mounting 60 path name length 60 QOpenSys file system 56 Network File System Differences 56 Network File System differences case-sensitivity 56 read/write options 56 QOPT file system 61, 62 Network File System differences 61 authorization 62 case-sensitivity 62 mounting 61 security 62 Q
startup (continued) NFS server STRNFSSVR command 67 NFS server scenario 66 state 4 statefulness definition 4 statelessness definition 4 STATFS command description 50 display 50 examples 53 OBJ parameter 51 purpose 50 STRNFSSVR command display 68 examples 69 NBRBIO parameter 69 NBSVR parameter 69 purpose 67 restrictions 68 SERVER parameter 69 STRJOBTIMO parameter 69 Sun Microsystems, Inc.
user-defined file system (UDFS) 15, 16, 17, 18, 19, 20, 23, 63 (continued) display 15 example 20 process 19 Network File System differences 62 auxiliary storage pools (ASPs) 63 case-sensitivity 63 Network File System functions 22 auxiliary storage pools (ASPs) 23 restoring 21 saving 21 unmount a UDFS 20 display 20 112 OS/400 Network File System Support V4R4
Readers’ Comments — We’d Like to Hear from You AS/400e OS/400 Network File System Support Version 4 Publication No.
SC41-5714-01 IBMR ___________________________________________________________________________________________________ Readers’ Comments — We’d Like to Hear from You Cut or Fold Along Line _ _ _ _ _ _ _Fold _ _ _ and _ _ _Tape _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Please _ _ _ _ do _ _ not _ _ _staple _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Fold _ _ _and _ _ Tape ______ NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES BUSINESS REPLY MAIL FIRST-CLASS MAIL PERMIT NO.
IBMR Printed in the United States of America on recycled paper containing 10% recovered post-consumer fiber.
Spine information: IBM AS/400e OS/400 Network File System Support V4R4 Version 4
