Mounting NFS Exports

Linux's NFS client is, essentially, the Linux kernel itself. The kernel treats another computer's NFS export as a filesystem that can be mounted via the mount command or an entry in /etc/fstab. Chapter 5, "Doing Real Work in Text Mode," Chapter 10, "Using Multiple OSs," and Chapter 12, "Filesystems and Files," all describe these tools to varying extents and in different contexts. The rules for using NFS exports are similar to those for using regular filesystems on partitions, although some details differ. To mount an NFS export, you specify the nfs filesystem type. In some cases, Linux can determine from context that you mean nfs, so you can sometimes omit this option. Instead of specifying a Linux device filename, you specify the host and export name. (For protection against a DNS server compromise or as a matter of preference, you can use an IP address rather than a hostname.) For instance, to mount/home from kranz.luna.edu at/mnt/morehome, you might type the following command:

# mount -t nfs kranz.luna.edu:/home /mnt/morehome

Tip If you don't know what exports a server makes available, you can type showmount -e servername. The result is a list of exports available orservername, along with the clients that can connect to each export.

In the case of the preceding example, you can omit the -t nfs specification, and if your client is in luna.edu or is configured to search that domain via a search line in /etc/resolv.conf, you can specify the export as kranz:/home rather than kranz.luna.edu:/home. If you want to mount an export whenever the computer boots or give ordinary users the power to mount an export, you can do so by adding an entry to /etc/fstab. For instance, the following line mounts this export at boot time: kranz.luna.edu:/home /mnt/morehome nfs defaults 0 0

You can add many standard mount options, as well; for instance, specifying an option of ro causes a read-only mount, even if the server has granted your system read/write access. (You cannot use rw to gain read/write access if the server gives you only read-only access, though.) There are also a few NFS-specific mount options. The most important of these may be hard and soft. Ordinarily or if you explicitly specify hard, a program trying to access an NFS server will hang if the server doesn't respond. When the server becomes available, the program will continue where it left off. If you specify soft, though, the kernel's NFS client will eventually time out and deliver an error message to the client. If your network or NFS server is flaky, you may prefer soft, because you'll be better able to kill processes that hang because of an inability to access NFS exports. If your network is functioning normally, though, hard is the preferred behavior, because specifying soft can cause occasional problems on a well-behaved network.

Once an export is mounted, all ordinary users can access that export, within limits imposed by file ownership and permissions. One potential caveat is that NFS uses user ID (UID) and group ID (GID) numbers in handling ownership and permissions. If users have accounts on both the client and the server computer, the users' UIDs and GIDs on those two systems must match, or the users won't be able to access their own files. A similar problem can arise if users have accounts on two or more clients that access the same server. Various workarounds have been deployed to fix this problem, but most aren't current. For instance, some older NFS servers supported options to map UIDs and GIDs between client and server; but the current Linux NFS server doesn't support this option. Your best bet is to synchronize UIDs and GIDs whenever necessary. Note that this practice isn't required for fundamentally public read-only exports, such as exports of directories holding software or shared read-only templates, unless some users should be restricted from accessing these files. Also, if an NFS server holds home directories but users don't need to log into that computer directly, you don't need to synchronize UIDs and GIDs because the users don't need accounts on the server. (You do still need to synchronize UIDs and GIDs across multiple clients in this case, though.) If the server doesn't have accounts for its NFS users, be sure any directory to which users should be able to write has permissions to enable world writing, or at least writing by the appropriate group, which in this case must be mapped appropriately.

Team LIB

Team LiB

^ previous

0 0

Post a comment