Using and Sharing Disk Resources with NFS In this section, we demonstrate ways that your Mac OS X machine can share resources with other Unix machines using NFS, the Network File System. We demonstrate two ways to set up your Mac OS X machine as an NFS client and one way to use it as an NFS server. A Common Way to Set Up the Tiger NFS Client In this section, we demonstrate a common method for setting up an NFS client on a Mac OS X machine. We show you this method because you will regularly see references to this type of code, for this and other NetInfo-related activities, on the Internet. Sometimes this type of method is the only method you can choose, so you need to be familiar with it. Sometimes, though, an alternative method might work better. For your Mac OS X machine to be a client machine, there has to be another Unix machine that is an NFS server. In other words, there has to be a Unix machine (Mac OS X or another flavor of Unix) on your network that is willing to export one of its filesystems to your Mac OS X machine. So, you cannot just set up your machine as a client and assume that everything will work fine. Discuss your interest in being able to use your Mac OS X machine to access a filesystem on another Unix machine with that machine's system administrator. There is a security risk involved, particularly for the other machine, when it shares its resources with your machine. Therefore, in that machine's interest, the system administrator might not be willing to export its filesystems to your machine. There might be some additional details to work out with your NFS server system administrator that we will not discuss in depth here, assuming that he feels you will responsibly control your machine and your use of the NFS server's resources. To avoid confusion on the remote host machine, it would be a good idea for users who are accessing the other machine's filesystem from your machine to have the same user and group IDs that they might already have on the remote host machine. Depending on how the remote host is set up, this might be no problem at all or a considerable annoyance. For example, if the remote host does not have user IDs in the same range as the users on your machine, the unusual user IDs might not be a problem. However, if users on your machine have user IDs in the same range as users on the remote host, files you create on the remote host with your user ID will be viewed by the remote host as being owned by the user native to that system that is, by whatever user lives on that system and has the same user ID. At any rate, if the system administrator of the remote machine agrees to export to your machine whichever filesystem you are interested in using, be aware that you still might have to work out some additional details with the system administrator. NFS gives both the client and server considerably more control over exactly how resources are shared (down to details such as how long to wait for a disk to become available again, if the network goes away) than a "point and mount" protocol such as AppleTalk/AppleShare. As your understanding of how to update the NetInfo database continues to improve in this chapter, any changes the system administrator of the remote host might request for your Mac OS X machine should not be difficult to make. With that said, let's continue to the details of setting up an NFS client on your Mac OS X machine. To be an NFS client, your machine must be running the right services. If you did not turn off any of the major default services, you do not need to worry about this. If you turned off NFS in the /System/Library/StartupItems/ directory, you have to turn it back on to be able to run your NFS client. NOTE You're not supposed to need to change these settings, but if your experience is like ours, the AUTOMATIC setting for NFSLOCKS specified in /etc/hostconfig won't actually work automatically for you. To get things working, we needed to edit /etc/hostconfig and set both of this to YES. |
It would also be a good idea to read the man pages for mount, mount_nfs, and fstab. The information that you will be adding to the NetInfo database is information regarding where your machine should mount a particular filesystem that resides on a remote host. When you are finished updating the NetInfo database, the remote host's filesystem appears to be local to your own machine. We include the syntax and primary options for the mount and mount_nfs commands in tables at the end of this section. A complete discussion of how to fully use all the power of NFS is the entire subject of more than one book. CAUTION You might need to disable the automounter to get your machine to properly mount NFS directories. This is accomplished by changing the setting in /etc/hostconfig to NO. This change was not necessary under 10.1.x versions of Mac OS X and, based on some information on the Internet, is not the case for all users of 10.2 and 10.3. However, we have seen several machines where the behavior of NFS is pathologically wrong when the automounter is enabled. The symptoms of the problem are The directory to which you attempt to mount the remote filesystem is deleted and replaced by a symbolic link to a directory in the /automount/ directory. The directory in the /automount/ cannot be entered, lsed, or otherwise read, but mount claims that the remote directory is mounted. The remote directory cannot be unmounted without rebooting the machine; you might also find that any attempt to read the supposedly mounted directory (even just trying to get its name to autoexpand at the command line using <TAB>) causes your shell to hang indefinitely.
If you experience these problems and still want to use NFS, disable the automounter by changing its YES enTRy to NO in /etc/hostconfig, and reboot your machine. With automount off, NFS should work in much more the fashion that the documentation suggests. |
AUTOMOUNTER ANTIFANS We aren't big fans of the automounter (/usr/sbin/automount). Even when it's working, it seems like the wrong thing to do. The automounter is supposed to be this magical (or at least poorly documented) utility that remembers filesystems that have been previously mounted and remounts them automatically whenever they're needed. The problem with this idea, other than the fact that in our cumulative 40-odd years of using Unix we've never seen a nontrivial system using automount where automount actually worked the way anyone wanted it to, is that automount removes control from the machine's administrator. You want to mount a directory of data under /usr/local/data/? The automounter, in all its wisdom, will insist on mounting it under /automounter/ and making a symbolic link to its mount point. Have software that won't work through a symbolic link? Tough. What's worse, on some systems, after it's seen a filesystem once, the automounter will keep mounting (or trying to mount) that filesystem forever, even after you've removed the control definition and tried to make it stop. With the exquisite level to which we're used to being able to configure and control our hardware, this behavior is simply unacceptable for a Unix machine. No, we aren't fans of the automounter at all, and we generally have it turned off on our systems just as a matter of principle. We won't tell you that you have to turn it off, and for lack of documentation, we aren't even sure what unusual twists Apple might have woven into its version. To make NFS work at all on the machines we tested 10.2 with, the automounter had to be turned off. We haven't had much trouble with 10.3, but it's been enough of a problem that we just don't trust it, so our examples are going to be based on the assumption that it's turned off. Some people make automount work on their machines and are happy with how it works, so you very well might be able to make these examples work or manage a setup in your own preferred configuration without shutting off automount. If you can, wonderful perhaps automount just hates us old curmudgeons. |
To add a filesystem from a remote host to your Mac OS X machine, do the following: 1. | Back up your NetInfo database.
| 2. | Plan where you want your Mac OS X machine to mount the remote host's filesystem. Unlike what you might be familiar with on AppleShare volumes, which mount as "drives" on the desktop, NFS filesystems can be grafted into your directory tree anywhere. Essentially, the directory structure rooted at the directory or file system that is exported can be made to appear exactly as it does on the remote host, as though it were any subdirectory of your choosing on your system.
The purpose of the remote filesystem might guide you in deciding where to mount it on your machine. For example, it is common, when a filesystem with a users' home directories are involved, that a machine mounting such a filesystem frequently does so in a directory hierarchy of /net/<remote_host>/home. If the remote filesystem is simply a filesystem used for storage, any way you want to mount it is probably suitable. Temporary mounts that you don't expect to reuse later are frequently done as subdirectories of /mnt/. Of course, you can change the name of the mount point and remount the filesystem later if you find that you do not like what you picked. Extra thought up front is particularly important, though, when the remote filesystem is used for users' home directories because more people than just yourself will need to know about and understand any changes that you make later on down the road.
In our example, we are going to mount a filesystem used for storage. On our machine, we want it to be mounted in a directory called /morespace/mother (mother is the name of the host that will serve the filesystem). We're creating the mount point in a subdirectory of the root directory, rather than directly in the root directory, because we might eventually want to add other storage filesystems from other remote hosts, and we want to be able to keep them straight. Another consideration would be a hierarchy similar to typical user hierarchies, such as /net/<remote_host>/morespace. If it's the only filesystem of its type that'll be mounted, there's no real need to have the mount point clearly include the host of origin.
After you have decided what to call the mount point, make it mount points are simply directories. They don't even have to be empty if you want the directory to contain one set of files when you have the remote system mounted and another when it's not. (A particularly nifty option available in the Mac OS X NFS client, union filesystems, allows you to see the files in both the local and remote directories simultaneously. See the mount_nfs docs for more information.)
brezup:root ray # cd / brezup:root / # mkdir morespace brezup:root / # mkdir morespace/mother brezup:root / # ls morespace/mother brezup:root / #
| 3. | Using your favorite text editor, create a file with the contents of the following form:
{ "opts" = ( "w" ); "dir" = ( "/<mountpoint>/" ); "name" = ( "<remote_host>:<remote_filesystem>"); "vfstype" = ( "nfs" ); }
Save it with Unix line endings rather than Mac line endings. Check again, to make sure that you really did.
Although many options are available for mounting, the one you will probably find most important initially is the read/write option after you've got that working, tweaking the nearly endless variety of options to customize the connection can be done at your leisure. On most systems, that option is rw. In Mac OS X, that option is w, although using the traditional rw also appears to work.
Here is a copy of the file we used:
{ "opts" = ( "w" ); "dir" = ( "/morespace/mother" ); "name" = ( "192.168.1.4:/innerspace"); "vfstype" = ( "nfs" ); }
/morespace/mother is where I want the remote filesystem to appear, 192.168.1.4 is the machine (also known as mother) serving it to me, and on mother, the directory that I'll be mounting is named /innerspace. I've named this file mount-test.txt, and it's in my current directory.
| 4. | Run niutil to create a new directory in the mounts directory of the NetInfo database:
brezup:root / # niutil -create . /mounts/new1
The new1 directory name is not important; it's going to be overwritten by information we're going to load into the database.
| 5. | Run niload to load the file into the NetInfo database:
brezup:root / # niload -r /mounts/new1 . < mount-test.txt
Notice that because you're providing a name and value in the data you're loading, the niload command renames the new1 subdirectory you just created. If you type as well as we do, you might have to run that statement a few times before it works. You might get messages indicating that there is an error at some line number in your input file. Just look at your file carefully and fix whatever needs to be fixed (especially, watch for things such as having saved the file with Mac line endings rather than Unix line endings).
| 6. | Look at the updates in the mounts section of the NetInfo database either using the command line or the NetInfo Manager. If you are using the command line, you might find it easier to see the values by directory number rather than directory name.
Here are the command-line results in our example as seen using niutil:
brezup:root / # niutil -list . /mounts 82 192.168.1.4:/innerspace brezup:root / # niutil -read . 82 opts: w dir: /morespace/mother name: 192.168.1.4:/innerspace vfstype: nfs
| 7. | After you have verified that the updates to your NetInfo database are correct, tell your machine to mount the filesystem, and take a look at what's happened:
brezup:root / # ls /morespace/mother/ brezup:root / # brezup:root / # mount -t nfs -a brezup:root / # ls /morespace/mother/ apache_1.3.26 tcpwrappers apache_1.3.26-src.tar wu-ftpd-2.6.1-linux-anon danspage wu-ftpd-2.6.1-linux-anon.tar.gz fcsafiles wu-ftpd-2.6.1-linux-both ftpaccess-mother-anon wu-ftpd-2.6.1-linux-both.tar.gz . . .
Suddenly, there's data in /morespace/mother/. However, it's not actually in/morespace/mother/; it's actually on the remote machine 192.168.1.4. This machine is only on the other side of the room, but there's no reason it couldn't be on the other side of the country.
|
At this point, you're supposed to be able to reboot your machine, and it should automatically mount that filesystem back up, without you needing to use the mount command. If your automounter is turned on, it'll definitely try (and it'll probably delete your/morespace/mother/ mount point for you while it tries). With automounter turned off, it doesn't appear that Apple takes the customary action of having a mount -t nfs -a command in its startup scripts, so you might need to add your own custom startup script to run mount for you. When you get this working at startup, or if automount is working for you, it might seem as if it takes your machine a little longer to reboot. This is to be expected. TIP If you later notice that it's suddenly taking a lot longer to start up, it might be because the NFS server that you've been mounting is not available. Depending on the options you configure, this can cause your machine to hang indefinitely. Such indefinite hangs aren't inevitable, however; check the man pages for the details regarding retries and under what conditions clients should allow a mount to fail. |
In addition to using mount to mount filesystems, you can run mount to see what is mounted where: brezup:root / # mount /dev/disk1s3 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol /dev/disk0s9 on /Volumes/Racer-9 (local) /dev/disk0s10 on /Volumes/Racer-X (local) /dev/disk0s11 on /Volumes/Wills_Data (local) /dev/disk0s12 on /Volumes/Software (local) /dev/disk0s13 on /Volumes/Temp (local) 192.168.1.4:/innerspace on /morespace/mother
The df command also tells you a bit about your mounts: brezup:root / # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/disk1s3 9715208 9093872 524184 95% / devfs 196 196 0 100% /dev fdesc 2 2 0 100% /dev <volfs> 1024 1024 0 100% /.vol /dev/disk0s9 1258104 994768 263336 79% /Volumes/Racer-9 /dev/disk0s10 10484800 9073632 1411168 87% /Volumes/Racer-X /dev/disk0s11 12581856 12147328 434528 97% /Volumes/Wills_Data /dev/disk0s12 10484800 8255520 2229280 79% /Volumes/Software /dev/disk0s13 4255160 3333520 921640 78% /Volumes/Temp 192.168.1.4:/innerspace 799494 677500 80716 89% /morespace/mother
Before we go on, let's look a little more closely at the directory that's coming from the mother server. Some of the things that you see with ls might be slightly unexpected: brezup:root / # ls -l /morespace/mother/ total 150318 drwxr-xr-x 9 ray ray 1024 27 Jun 2002 apache_1.3.26 -rw-r--r-- 1 ray ray 9728000 20 Jun 2002 apache_1.3.26-src.tar drwxr-xr-x 7 software wheel 1024 26 Jul 1999 danspage drwxr-xr-x 2 ray wheel 1024 23 Feb 2000 fcsafiles -rw-r--r-- 1 root wheel 1918 4 Dec 2001 ftpaccess-mother-anon -rw-r--r-- 1 root wheel 2046 4 Dec 2001 ftpaccess-mother-w2ftp drwxr-xr-x 2 ray ray 1024 23 Aug 2002 ispell -rw-r--r-- 1 ray ray 14239859 28 Apr 2002 j2re-1_3_1_01-linux-i386-rpm -rw-r--r-- 1 root wheel 14363657 8 Aug 2001 jre-1.3.1_01.i386.rpm -rw-r--r-- 1 18940 101 29388800 15 Nov 2002 krb5-1.2.7-i686-pc-linux-gnu.tar -rw-r--r-- 1 18940 101 303 15 Nov 2002 krb5-1.2.7-i686-pc-linux-gnu.tar  .gz.asc . . . drwxr-xr-x 8 ray 10 1024 4 Dec 2001 wu-ftpd-2.6.2-linux-anon -rw-r--r-- 1 root wheel 956301 4 Dec 2001 wu-ftpd-2.6.2-linux-anon.tar.gz drwxr-xr-x 8 ray 10 1024 4 Dec 2001 wu-ftpd-2.6.2-linux-w2ftp -rw-r--r-- 1 root wheel 956309 4 Dec 2001 wu-ftpd-2.6.2-linux-w2ftp.tar.gz -rw-r--r-- 1 600 software 351958 4 Dec 2001 wu-ftpd-2.6.2-src.tar.gz
Notice how some of the files don't have proper owners and/or groups, and instead show only numeric UID and GID entries. This is because I don't have the user and groups list synchronized between these machines. mother's a Linux box that sits in the kitchen and runs my home network, so I have a few users on it that match, but I do most of my work on my Mac OS X laptop. Because of this, I've configured mother so that the main user IDs and groups that I use on both machines match, but a number of users on each machine are unique to that system. The UID/GID matching for mounted directories is done based on the numeric value of the UID and GID, so the shared users appear to own their own files, but the nonshared users and groups coming from mother have no analogous users on my Mac OS X laptop, so they only show up as numbers. As a matter of fact, from NFS's point of view, there's really no guarantee that mother doesn't think that the numeric UID that my laptop knows as ray is really named fred. And from my laptop's point of view, it really doesn't care what mother thinks the usernames are; it's just showing names based on what its NetInfo users list says goes with the numeric UIDs and GIDs that mother's reporting for the files. In addition to listing and looking at statistics about the remote filesystem, you can of course now access the remote filesystem as if it were local to your machine. As mentioned earlier, you might have to work out some details with the system administrator of the remote machine. One of the details you might have to work out is making sure that there is a directory on that filesystem that you are allowed to write to. In our example, there is a public directory on the remote filesystem that we are allowed to use. The mount options can be configured to allow all users writing access, only some users, only some users to only some directories, and an assortment of other useful combinations. An Easier Way to Set Up an NFS Client in Mac OS X As you might recall from the section on adding a printer through the command line, the niload command can recognize some regular Unix flat-file formats. The format we saw earlier, printcap, is one of them. It turns out that the file that controls mount points, fstab, is another of those formats. We recommend that, where possible, you use niload in combination with formats it might already recognize rather than have it load in raw NetInfo format. Because the Unix flat-file formats are easier to type, you will make fewer typing errors. In addition, if you take the time to familiarize yourself with the regular Unix flat files, you will be even better prepared to understand information that relates to other Unix platforms. Even though the traditional formats are options for your system, most of the rest of the Unix-using world is comfortable with them and will give advice and suggestions using these formats. When you've loaded data from a file in a traditional control format into NetInfo, always take the time to check the information that's landed in the NetInfo database, not only to confirm that everything was done properly, but also to learn the native Mac OS X formats. In this section, we show you an easier way to enter the mounts information into the NetInfo database than the one we used for /morespace/mother/. Although this is easier, be aware that you still have to coordinate with the system administrator of the remote host. To set up an NFS client on a Mac OS X machine, you can also do the following: 1. | Back up the NetInfo database.
| 2. | Create the local mount point for the remote filesystem.
| 3. | Create a one-line file containing the mount information. The one-line file has these fields, which can be separated by spaces or tabs:
Field | Value |
|---|
1 | Remote filesystem to be mounted, including the machine it's being mounted from. The syntax is as shown earlier: <machine>:<directory to mount>. | 2 | Local mount point. | 3 | Filesystem type (for NFS, it's nfs). | 4 | mount options. | 5 | Interval between dumps. | 6 | Order in which fsck is run at boot time. |
Fields 5 and 6 are traditional parts of the format but do not apply to remote filesystems. Those values can either be absent or can be 0.
Here is the fstab used in this examples note that we can use rosalyn as the server name here instead of a fully qualified domain name (complete hostname) because this machine is in the same domain as rosalyn, and we have configured this domain as a local search domain via the Network control pane. You might need to use either a FQDN or an IP address for the server, depending on your configuration:
rosalyn:/space /extraspace nfs rw 0 0
| 4. | Run niload to load the fstab format file into the NetInfo database. In our example, we used fstab-test as the fstab formatted file:
brezup:root / # niload fstab . < fstab-test
Verify that the data was loaded properly into the NetInfo database using either the command line or the NetInfo Manager.
| 5. | Mount the filesystem with mount -t nfs -a, and check your results as previously demonstrated.
Run the same sorts of command-line tools you ran in the previous section, such as mount and ls. If your automounter is working for you, you might also want to check the list of volumes on your Mac OS X desktop, and/or the /Computer/Network/Servers path in the Finder, because you will hopefully find a pleasant surprise there, too. Behavior here seems inconsistent, and what mount points will be seen as remote servers and what won't are still a bit of a mystery to us.
|
NOTE Any changes you make to the NFS mounts by tweaking the NetInfo database and manually running mount are available immediately via the command line. If you want to make the NFS mounts available via the Finder immediately as well, you might have to reboot after making your changes to the mounts in the NetInfo database. There's undoubtedly a process or two that could be restarted to cause the Finder to recognize the existence of the new network disk resources, but we haven't made this work reliably yet. Restarting is slow, but bulletproof. |
Table 20.7 shows the syntax and most useful options for mount, and Table 20.8 covers mount_nfs, the underlying command that mount calls. Table 20.9 covers umount. Table 20.7. The mount Command Syntax and Important Optionsmount | Mounts filesystems. | mount | mount [-adfruvw] [-t ufs | lfs | <external_type>] | mount [-dfruvw] <special> | <node> | mount [-dfruvw] [-o <options>] [-t ufs | lfs | <external_type>] <special> | <node> | mount invokes a filesystem-specific program to prepare and graft the <special> device or remote node (rhost:path) on the file system tree at the point <node>. If neither <special> nor <node> is specified, the appropriate information is taken from the fstab file. | The system maintains a list of currently mounted filesystems. If no arguments are given to mount, this list is displayed. | -a | All the filesystems described in your NetInfo mounts directory or fstab control file are mounted. Exceptions are those marked as noauto or are excluded by the -t flag. | -r | Mounts the filesystem read-only (even root may not write to it). The same as the rdonly subargument to the -o option. | -u | Indicates that the status of an already mounted filesystem should be changed. Any of the options available in -o may be changed. The filesystem may be changed from read-only to read-write or vice versa. An attempt to change from read-write to read-only fails if any files on the filesystem are currently open for writing unless -f is also specified. | -v | Enables verbose mode. | -w | Sets the filesystem object to read-write. | -t ufs | lfs |<external_type> | Specifies a filesystem type. Default is type ufs. The option can also be used to indicate that the actions should be performed only on the specified filesystem type. More than one type may be specified in a comma-separated list. The prefix no added to the type list may be used to specify that the actions should not take place on a given type. For example, mount -a -t nonfs,mfs indicates that all filesystems should be mounted except those of type NFS and MFS. mount attempts to execute a program called mount_XXX where XXX is the specified typename. | -o | Specifies certain options. The options are specified in a comma-separated list. | The following options are available for the -o option: | noauto | Skips this filesystem when mount is run with the -a flag. | nodev | Does not interpret character or block special devices on the filesystem. The option is useful for a server that has filesystems containing special devices for architectures other than its own. | noexec | Does not allow the execution of any binaries on the mounted filesystem. This option is useful for a server containing binaries for an architecture other than its own. | nosuid | Does not allow set-user-identifier or set-group-identifier bits to take effect. | rdonly | Same as -r. Mounts the filesystem read-only. Even root may not write to it. | union | Causes the namespace (that is, the files that appear there) at the mount point to appear as the union of the mounted filesystem root and the existing directory. Lookups are done on the mounted filesystem first. If operations fail due to a nonexistent file, the underlying filesystem is accessed instead. All new files and directories are created in the mounted filesystem. | Any additional options specific to a given filesystem type may be passed as a comma-separated list. The options are distinguished by a leading -. Options that take a value have the syntax -<option>=<value>. |
Table 20.8. The mount_nfs Syntax and Important Optionsmount_nfs | Mounts NFS filesystems. | mount_nfs [-23KPTUbcdilqs] [-D <deadthresh>] [-I <readdirsize>] [-L <leaseterm>] [-R <retrycnt>] [-a <maxreadahead>] [-g <maxgroups>] [-m <realm>] [-o <options>] [-r <readsize>] [-t <timeout>] [-w <writesize>] [-x <retrans>] <rhost>:<path> <node> | -T | Uses TCP transport instead of UDP. This is recommended for servers not on the same LAN cable as the client. This is not supported by most non-BSD servers. | -U | Forces the mount protocol to use UDP transport, even for TCP NFS mounts. Necessary for some old BSD servers. | -b | Backgrounds the mount. If a mount fails, forks a child process that keeps trying the mount in the background. This option is useful for a filesystem not critical to multiuser operation. | -c | Does not perform a connect for UDP mounts. This must be used for servers that do not reply to requests from the standard NFS port number 2049. It might also be required for servers with more than one IP address if replies come from an address other than the one specified in the mount request. | -d | Turns off the dynamic retransmit timeout estimator. This might be useful for UDP mounts that exhibit high retry rates; it is possible for the dynamically estimated timeout to be too short. | -i | Makes the mount interruptible. The filesystem calls that are delayed due to an unresponsive server fail with EINTR when a termination signal is posted for the process. | -s | Soft mount. Filesystem calls fail after <retrycnt> round-trip timeout intervals. | -R <retrycnt> | Sets the retry count for doing the mount to <retrycnt>. | -a <maxreadahead> | Sets the read-ahead count to <maxreadahead>. This value may be in the 0 4 range, and determines how many blocks are read ahead when a large file is being read sequentially. A value larger than 1 is suggested for mounts with a large bandwidth * delay product. | -o <options> | Options are specified as a comma-separated list of options. See mount for a listing of the available options. | -r <readsize> | Sets the read data size to <readsize>. It should normally be a power of 2 >= 1024. This should be used for UDP mounts when the fragments dropped due to timeout value are getting large while actively using a mount point. Use netstat -s to get the fragments dropped due to timeout value. See the -w option. | -t <timeout> | Sets the initial retransmit timeout to <timeout>. Might be useful for fine-tuning UDP mounts over networks with high packet loss rates or an overloaded server. Try increasing the interval if nfsstat shows high retransmit rates while the filesystem is active, or try reducing the value if there is a low retransmit rate but long response delay observed. Normally the -d option is also used when using this option to fine-tune the timeout interval. | -w <writesize> | Sets the write data size to <writesize>. See comments regarding the -r option, but using the fragments dropped due to timeout value on the server rather than the client. The -r and -w options should be used only as a last resort to improve performance when mounting servers that do not support TCP mounts. | -x <retrans> | Sets the retransmit timeout count for soft mounts to <retrans>. |
Table 20.9. The Syntax and Primary Options for umountumount | Unmounts filesystems. | umount [-fv] <special> | <node> | umount -a | -A [-fv] [-h <host>] [-t <type>] | -f | Forcibly unmounts the filesystem. Active special devices continue to work, but all other files return errors if further accesses are attempted. The root filesystem cannot be forcibly unmounted. | -v | Enables verbose mode. | -a | All the filesystems described in fstab are unmounted. | -A | All the currently mounted filesystems except the root are unmounted. | -h <host> | Unmounts only filesystems mounted from the specified <host>. This option implies the -A option and, unless otherwise specified with the -t option, will only unmount NFS filesystems. | -t <type>_ | Is used to indicate that actions should be taken only on filesystems of the specified <type>. More than one type may be specified in a comma-separated list. The list of filesystem types can be prefixed with no to specify the filesystem types for which action should not be taken. For example, the umount command umount -a -t nfs,mfs unmounts all filesystems of the type NFS and MFS. |
Serving NFS on Tiger As the prices of IDE storage continue to drop, the absolute necessity to share disk space is disappearing. Still, it's often convenient if you can share your files and disk space to other machines you use, so that work you do on one is available on all. If you are interested in serving one of your filesystems to another Mac OS X machine, AppleShare might be good enough for some purposes, but NFS works for serving data to any Unix machine. Because we find NFS to be both more powerful and more complicated to get right, and AppleShare to be almost completely automated by the single check box in the Sharing system pane, we'll detail exporting your filesystems as NFS resources. However, if you are interested in powerfully exporting via AppleShare, you might take a look at SharePoints, available at http://www.hornware.com/sharepoints/. Just as setting up your machine to be an NFS client requires coordination with the system administrator of the remote Unix machine, so does serving a filesystem to a remote Unix machine. Remember, this reduces security on both systems, especially yours. Do not consider doing this unless you can trust the remote host. Depending on the system setups, coordination between user IDs might be necessary, especially if you want to make the drive available to users other than yourself. The other system administrator should be able to guide you through any additional details that might need to be coordinated. The other Unix system administrator will set up the remote host to be able to mount your filesystem. You will have to set up your machine to export a filesystem to a remote host. At this time, you should read the exports man page. If you plan to create your exports through the command line, you might want to take this opportunity to look at the nidump command as well. As the name suggests, nidump dumps information from the NetInfo database to standard output. It can dump information to a flat file in a number of traditional Unix configuration file formats. It can also dump information in a format that can be read back into and understood by the NetInfo database. This format is both more general and less conveniently human-readable than the typical Unix flat configuration-file format. Because it's a generalized format that works for any NetInfo data, it can be used to import data for directory structures that don't have an analogous Unix flat-file format. To learn more about this format, you might find running nidump on one of the NetInfo directories that you know something about to be a useful way of seeing the syntax used to create a new directory and directories under it. Here is what the nidump output from the mount examples in the previous section looks like: [localhost:~] software% nidump -r /mounts . { "name" = ( "mounts" ); CHILDREN = ( { "vfstype" = ( "nfs" ); "passno" = ( "0" ); "dir" = ( "/extraspace" ); "dump_freq" = ( "0" ); "name" = ( "rosalyn:/space" ); "opts" = ( "w" ); }, { "opts" = ( "w" ); "dir" = ( "/morespace/mother" ); "name" = ( "1921.68.1.4:/innerspace" ); "vfstype" = ( "nfs" ); } ) }
Not only does nidump provide an example of the syntax used to create a directory and subdirectories, but, as we saw with skeleton user accounts section, the output from a nidump command can also provide the basis for a file that you could edit for setting up your exports. This would already provide much of the complicated part of the syntax and enable you to just edit values suitable for exports instead. To set up your Mac OS X machine to export a filesystem to a remote Unix host, do the following: 1. | Back up the NetInfo database.
| 2. | If you plan to export a filesystem that currently contains a space in the name, change its name to something that does not have a space. Mac OS and Mac OS X deal with spaces okay, but they confuse many more traditional Unix systems. If you're only going to be working among Mac OS X systems, spaces might be all right, but you'll probably find that they will eventually be trouble. The same goes for most characters outside basic alphanumerics.
| 3. | Enter exports information into the NetInfo database. Unfortunately, despite what the man page says, the niload command currently does not understand the typical exports format. So, in this case, you cannot make an exports format file and load that into NetInfo. You must either make a file that follows the same kind of format you saw in the first mount example (the format with braces, parentheses, and quotes), or you must enter the information into the NetInfo database using the NetInfo Manager.
Because I am so poor at balancing all the appropriate characters, parentheses, and quotes needed to make one of the raw NetInfo files, I prefer to do this through the NetInfo Manager. Our instructions are specifically for the NetInfo Manager. However, you should choose whichever method you are most comfortable with.
Open the NetInfo Manager, and select the local domain. Click in the lock to make changes, and enter the administrator username and password. With the root (/) directory selected, select Directory, New Subdirectory from the menu. Change the name of new_directory to exports, and save the change.
| 4. | Click the exports directory. Select Directory, New Subdirectory from the menu. Give this subdirectory the name of the filesystem you want to export. Save it. Now select the new directory and add a clients property whose value is a list of clients that the filesystem should be exported to use insert value with the clients property selected to add multiple client values. Add an opts property with any options you want to specify, based on the exports man page ro is common if you want the filesystem to be read-only to remote clients that mount it, whereas rw allows read-write access. alldirs allows clients to mount arbitrary subdirectories from the filesystem instead of the whole filesystem.
Figure 20.12 shows the settings that we used for exporting our filesystem. Note that you should not use the maproot mapping option we used, maproot=root, unless you can trust the remote system and administrator as highly as you trust your own.
Figure 20.12. Here are the settings we used for exporting our /Volumes/huge filesystem. 
| 5. | Save your changes to the exports directory and then restart the NetInfo servers for your local domain. Click the lock to prevent further changes.
| 6. | Reboot the machine and then test the results. Alternatively, you can (as root) run SystemStarter start NFS (or, if you've already got NFS exports and are just making changes, SystemStarter restart NFS).
A quick test that you can do on your Mac OS X machine is to run mount:
brezup:ray ray $ mount /dev/disk1s3 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol /dev/disk0s9 on /Volumes/Racer-9 (local) /dev/disk0s10 on /Volumes/Racer-X (local) /dev/disk0s11 on /Volumes/Wills_Data (local) /dev/disk0s12 on /Volumes/Software (local) /dev/disk0s13 on /Volumes/Temp (NFS exported, local) rosalyn:/space on /extraspace 192.168.1.4:/innerspace on /morespace/mother
Note that the Mac OS X machine indicates that /Volumes/huge is being served as an NFS export as well as mounted locally.
Another quick test that you can run shows what clients your volume is exported to:
brezup:ray ray $ showmount -e Exports list on localhost: /Volumes/huge 192.168.1.13
Now you need to add your machine to the remote machine's mount list. If the remote machine is a Mac OS X machine, this is just like adding the morespace or extraspace mount points we used in earlier examples. If the remote machine is a Linux box or another form of Unix box, the administrator needs to add an fstab line similar to what we used to load the extraspace mount into our NetInfo database. Here, we're mounting brezup's /Volumes/Temp on rosalyn, a Sun Solaris machine at the mount point /net/brezup/huge. After the mount point has been defined, run mount -t nfs -a on the remote machine.
Test that the remote host agrees with the Mac OS X machine:
Rosalyn joray 87 > ls /net/brezup/huge AppleShare PDS TheFindByContentFolder osx-misc.tar Desktop DB TheVolumeSettingsFolder test Desktop DF Trash â¢T+â¢It's HUUUGE Desktop Folder lpd-spool-working.tar
If we check the filesystem locally, we find the same ls listing:
brezup:ray ray $ ls /Volumes/huge AppleShare PDS TheFindByContentFolder osx-misc.tar Desktop DB TheVolumeSettingsFolder test Desktop DF Trash ???T+???It's HUUUGE Desktop Folder lpd-spool-working.tar
NOTE Notice the file with the weird characters in the name in each listing. They appear to be different because the character sets used by the two machines aren't quite the same, and neither one can display that name properly it has Macintosh special characters in it. |
When you are satisfied that the export is working properly, remember that your machine is now serving data to another machine. Consequently, it might seem as if it takes a little longer for it to shut down at shutdown or reboot time. Do not panic. This is expected. If you plan for your exported filesystem to be of regular use, try to keep the number of reboots to a minimum. After your machine has started serving data to another machine, it is not just your machine or a machine for your local users it is a machine that users on a remote host could come to rely on.
|
Table 20.10 shows the syntax and primary configuration options of exports enTRies. Table 20.10. The Syntax and Primary Configuration Options for exports SettingsExports | Defines remote mount points for NFS requests. | The exports file specifies remote mount points for NFS mount protocol per the NFS server specification. | In a mount enTRy, the first field specifies the directory path within a server filesystem that clients can mount. There are two forms of this specification. The first form is to list all mount points as absolute directory paths separated by whitespace. The second form is to specify the pathname of the root of the filesystem followed by the -alldirs flag. This form allows hosts to mount at any point within the filesystem, including regular files if the -r option is used in mountd. The pathnames should not have any symbolic links, or . or .. components. | The second component of a line specifies how the filesystem is to be exported to the host set. The options specify whether the filesystem is exported read-only or read-write and how the client UID is mapped to user credentials on the server. | The third component of a line specifies the client host set. The set may be specified in three ways. The first is to list the hostnames separated by whitespace. Standard Internet dot addresses may be used instead. The second way is to specify a netgroup, as defined in netgroup. The third way is to specify an Internet subnetwork using a network and network mask. | Export options are as follows: | -maproot=user | Credential of the specified user is used for remote access by root. The credential includes all groups to which the user is a member on the local machine. The user may be specified by name or number. | -mapall=user | -r | Synonym for -maproot for backward compatibility with older export file formats. | When neither -maproot nor -mapall is specified, remote accesses by root result in a credential of-2:-2. All other users are mapped to their remote credential. If a -maproot option is given, remote access by root is mapped according to the specified value instead of -2:-2. If -mapall is given, the credentials of all users, including root, are mapped as specified. | -ro | Specifies that the filesystem should be exported read-only. |
If the basic ways available to you in Mac OS X for sharing resources seem a bit overwhelming, you might be interested in a shareware product called NFS Manager, available at http://www.bresink.de/osx/. It provides GUI interface controls for both NFS mounts and exports. Figure 20.13 shows a sample of the interface. At the time of this writing, some portions of it seem to rely on the automounter running, so if you've shut off yours, you might be able to use NFS Manager to create configurations, but you'll need to mount them manually at the command line. On the other hand, some people are happy with it running hand-in-hand with the automounter, so this could be a good option for you as well. It's also handy for the exploratory purpose of fiddling with settings and then examining the NetInfo database to see exactly what it's done to configure a mount point or export. Figure 20.13. Here is a sample of what the interface for the shareware product NFS Manager looks like. It can manage both mount and exports configuration. 
|
