Differences between current version and previous revision of HowToNFSHOWTO.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 3 | Last edited on Friday, October 29, 2004 10:10:14 am | by StuartYeates | |
| Older page: | version 2 | Last edited on Friday, June 7, 2002 1:07:10 am | by perry | Revert |
@@ -1,2620 +1 @@
-Linux NFS-HOWTO
-!!!Linux NFS-HOWTO
-!Tavis Barr
-
- tavis@mahler.econ.columbia.edu
-
-
-
-!Nicolai Langfeldt
-
- janl@linpro.no
-
-
-
-!Seth Vidal
-
- skvidal@phy.duke.edu
-
-
-
-
-2000-12-28
-
-----; __Table of Contents__; 1. Preamble: ; 1.1. Legal stuff; 1.2. Disclaimer; 1.3. Feedback; 1.4. Translation; 1.5. Dedication; 2. Introduction: ; 2.1. What is NFS?; 2.2. What is this HOWTO and what is it not?; 2.3. Knowledge Pre-Requisites; 2.4. Software Pre-Requisites: Kernel Version and nfs-utils; 2.5. Where to get help and further information; 3. Setting Up an NFS Server: ; 3.1. Introduction to the server setup; 3.2. Setting up the Configuration Files; 3.3. Getting the services started; 3.4. Verifying that NFS is running; 3.5. Making changes to /etc/exports later on; 4. Setting up an NFS Client: ; 4.1. Mounting remote directories; 4.2. Getting NFS File Systems to Be Mounted at Boot Time; 4.3. Mount options; 5. Optimizing NFS Performance: ; 5.1. Setting Block Size to Optimize Transfer Speeds; 5.2. Packet Size and Network Drivers; 5.3. Number of Instances of NFSD; 5.4. Memory Limits on the Input Queue; 5.5. Overflow of Fragmented Packets; 5.6. Turning Off Autonegotiation of NICs and Hubs; 5.7. Non-NFS-Related Means of Enhancing Server Performance; 6. Security and NFS: ; 6.1. The portmapper; 6.2. Server security: nfsd and mountd; 6.3. Client Security; 6.4. NFS and firewalls (ipchains and netfilter); 6.5. Summary; 7. Troubleshooting: ; 7.1. Unable to See Files on a Mounted File System; 7.2. File requests hang or timeout waiting for access to the file.; 7.3. Unable to mount a file system; 7.4. I do not have permission to access files on the mounted volume.; 7.5. When I transfer really big files, NFS takes over
-all the CPU cycles on the server and it screeches to a halt.; 7.6. Strange error or log messages; 7.7. Real permissions don't match what's in /etc/exports.; 7.8. Flaky and unreliable behavior; 7.9. nfsd won't start; 8. Using Linux NFS with Other OSes: ; 8.1. AIX; 8.2. BSD; 8.3. Compaq Tru64 Unix; 8.4. HP-UX; 8.5. IRIX; 8.6. Solaris; 8.7. SunOS
-!!!1. Preamble
-!!1.1. Legal stuff
-
-Copyright (c) `2001b by Tavis Barr, Nicolai Langfeldt, and Seth Vidal.
-This material may be distributed only subject to the terms and conditions set
-forth in the Open Publication License, v1.0 or later (the latest version
-is presently available at http://www.opencontent.org/openpub/).
-
-----
-!!1.2. Disclaimer
-
-This document is provided without any guarantees, including
-merchantability or fitness for a particular use. The maintainers
-cannot be responsible if following instructions in this document
-leads to damaged equipment or data, angry neighbors, strange habits,
-divorce, or any other calamity.
-
-----
-!!1.3. Feedback
-
-This will never be a finished document; we welcome feedback about
-how it can be improved. As of October 2000, the Linux NFS home
-page is being hosted at http://nfs.sourceforge.net. Check there
-for mailing lists, bug fixes, and updates, and also to verify
-who currently maintains this document.
-
-
-----
-!!1.4. Translation
-
-If you are able to translate this document into another language,
-we would be grateful and we will also do our best to assist you.
-Please notify the maintainers.
-
-----
-!!1.5. Dedication
-
-NFS on Linux was made possible by a collaborative effort of many
-people, but a few stand out for special recognition. The original
-version was developed by Olaf Kirch and Alan Cox. The version 3
-server code was solidified by Neil Brown, based on work from
-Saadia Khan, James Yarbrough, Allen Morris, H.J. Lu, and others
-(including himself). The client code was written by Olaf Kirch and
-updated by Trond Myklebust. The version 4 lock manager was developed
-by Saadia Khan. Dave Higgen and H.J. Lu both have undertaken the
-thankless job of extensive maintenance and bug fixes to get the
-code to actually work the way it was supposed to. H.J. has also
-done extensive development of the nfs-utils package. Of course this
-dedication is leaving many people out.
-
-
-
-The original version of this document was developed by Nicolai
-Langfeldt. It was heavily rewritten in 2000 by Tavis Barr
-and Seth Vidal to reflect substantial changes in the workings
-of NFS for Linux developed between the 2.0 and 2.4 kernels.
-Thomas Emmel, Neil Brown, Trond Myklebust, Erez Zadok, and Ion Badulescu
-also provided valuable comments and contributions.
-
-----
-!!!2. Introduction
-!!2.1. What is NFS?
-
- The Network File System (NFS) was developed to allow machines
-to mount a disk partition on a remote machine as if it were on
-a local hard drive. This allows for fast, seamless sharing of
-files across a network.
-
-
-
-
- It also gives the potential for unwanted people to access your
-hard drive over the network (and thereby possibly read your email
-and delete all your files as well as break into your system) if
-you set it up incorrectly. So please read the Security section of
-this document carefully if you intend to implement an NFS setup.
-
-
-
-
- There are other systems that provide similar functionality to NFS.
-Samba provides file services to Windows clients. The Andrew File
-System from IBM (http://www.transarc.com/Product/EFS/AFS/index.html),
-recently open-sourced, provides a file sharing mechanism with some
-additional security and performance features. The Coda File System
-(http://www.coda.cs.cmu.edu/) is still in development as of this writing
-but is designed to work well with disconnected clients. Many of the
-features of the Andrew and Coda file systems are slated for inclusion
-in the next version of NFS (Version 4) (http://www.nfsv4.org). The
-advantage of NFS today is that it is mature, standard, well understood,
-and supported robustly across a variety of platforms.
-
-
-----
-!!2.2. What is this HOWTO and what is it not?
-
- This HOWTO is intended as a complete, step-by-step guide to setting
-up NFS correctly and effectively. Setting up NFS involves two steps,
-namely configuring the server and then configuring the client. Each
-of these steps is dealt with in order. The document then offers
-some tips for people with particular needs and hardware setups, as
-well as security and troubleshooting advice.
-
-
-
-
- This HOWTO is not a description of the guts and
-underlying structure of NFS. For that you may wish to read
-''Managing NFS and NIS'' by Hal Stern, published by O'Reilly 8
-Associates, Inc. While that book is severely out of date, much
-of the structure of NFS has not changed, and the book describes it
-very articulately. A much more advanced and up-to-date technical
-description of NFS is available in ''NFS Illustrated'' by Brent Callaghan.
-
-
-
-
- This document is also not intended as a complete reference manual,
-and does not contain an exhaustive list of the features of Linux
-NFS. For that, you can look at the man pages for ''nfs(5)'',
-''exports(5)'', ''mount(8)'', ''fstab(5)'',
-''nfsd(8)'', ''lockd(8)'', ''statd(8)'',
-''rquotad(8)'', and ''mountd(8)''.
-
-
-
-
- It will also not cover PC-NFS, which is considered obsolete (users
-are encouraged to use Samba to share files with PC's) or NFS
-Version 4, which is still in development.
-
-
-----
-!!2.3. Knowledge Pre-Requisites
-
- You should know some basic things about TCP/IP networking before
-reading this HOWTO; if you are in doubt, read the
-Networking-
-Overview-HOWTO.
-
-
-----
-!!2.4. Software Pre-Requisites: Kernel Version and nfs-utils
-
- The difference between Version 2 NFS and version 3 NFS will be
-explained later on; for now, you might simply take the suggestion
-that you will need NFS Version 3 if you are installing a dedicated
-or high-volume file server. NFS Version 2 should be fine for
-casual use.
-
-
-
-
- NFS Version 2 has been around for quite some time now (at least
-since the 1.2 kernel series) however you will need a kernel version
-of at least 2.2.18 if you wish to do any of the following:
-
-
-
-
-
-*
-
-Mix Linux NFS with other operating systems' NFS
-
-
-*
-*
-
-Use file locking reliably over NFS
-
-
-*
-*
-
-Use NFS Version 3.
-
-
-*
-
-
-
-
- There are also patches available for kernel versions above 2.2.14
-that provide the above functionality. Some of them can be downloaded
-from the Linux NFS homepage. If your kernel version is 2.2.14-
-2.2.17 and you have the source code on hand, you can tell if these
-patches have been added because NFS Version 3 server support will be
-a configuration option. However, unless you have some particular
-reason to use an older kernel, you should upgrade because many bugs
-have been fixed along the way.
-
-
-
-
- Version 3 functionality will also require the nfs-utils package of
-at least version .1.6, and mount version 2.10m or newer. However
-because nfs-utils and mount are fully backwards compatible, and because
-newer versions have lots of security and bug fixes, there is no good
-reason not to install the newest nfs-utils and mount packages if you
-are beginning an NFS setup.
-
-
-
-
- All 2.4 and higher kernels have full NFS Version 3 functionality.
-
-
-
-
- All kernels after 2.2.18 support NFS over TCP on the client side.
-As of this writing, server-side NFS over TCP only exists in the
-later 2.2 series (but not yet in the 2.4 kernels), is considered
-experimental, and is somewhat buggy.
-
-
-
-
- Because so many of the above functionalities were introduced in
-kernel version 2.2.18, this document was written to be consistent
-with kernels above this version (including 2.4.x). If you have an
-older kernel, this document may not describe your NFS system
-correctly.
-
-
-
-
- As we write this document, NFS version 4 is still in development
-as a protocol, and it will not be dealt with here.
-
-
-----
-!!2.5. Where to get help and further information
-
- As of November 2000, the Linux NFS homepage is at
-http://nfs.sourceforge.net. Please check there for NFS related
-mailing lists as well as the latest version of nfs-utils, NFS
-kernel patches, and other NFS related packages.
-
-
-
-
- You may also wish to look at the man pages for ''nfs(5)'',
-''exports(5)'', ''mount(8)'', ''fstab(5)'',
-''nfsd(8)'', ''lockd(8)'', ''statd(8)'',
-''rquotad(8)'', and ''mountd(8)''.
-
-
-----
-!!!3. Setting Up an NFS Server
-!!3.1. Introduction to the server setup
-
- It is assumed that you will be setting up both a server and a
-client. If you are just setting up a client to work off of
-somebody else's server (say in your department), you can skip
-to Section 4. However, every client that is set up requires
-modifications on the server to authorize that client (unless
-the server setup is done in a very insecure way), so even if you
-are not setting up a server you may wish to read this section to
-get an idea what kinds of authorization problems to look out for.
-
-
-
-
- Setting up the server will be done in two steps: Setting up the
-configuration files for NFS, and then starting the NFS services.
-
-
-----
-!!3.2. Setting up the Configuration Files
-
- There are three main configuration files you will need to edit to
-set up an NFS server: /etc/exports,
-/etc/hosts.allow, and /etc/hosts.deny.
-Strictly speaking, you only need to edit /etc/exports to get
-NFS to work, but you would be left with an extremely insecure setup. You may also need
-to edit your startup scripts; see Section 3.3.3 for more on that.
-
-
-----
-!3.2.1. /etc/exports
-
- This file contains a list of entries; each entry indicates a volume
-that is shared and how it is shared. Check the man pages (__man
-exports__) for a complete description of all the setup options for
-the file, although the description here will probably satistfy
-most people's needs.
-
-
-
-
- An entry in /etc/exports will typically look like this:
-
- directory machine1(option11,option12) machine2(option21,option22)
-
-
-
- where
-; __directory__:
-
- the directory that you want to share. It may be an
-entire volume though it need not be. If you share a directory,
-then all directories under it within the same file system will
-be shared as well.
-
-
-; __machine1 and machine2__:
-
- client machines that will have access to the directory. The machines
-may be listed by their IP address or their DNS address
-(e.g., ''machine.company.com'' or ''192.168..8'').
-Using IP addresses is more reliable and more secure.
-
-
-; __optionxx__:
-
- the option listing for each machine will describe what kind of
-access that machine will have. Important options are:
-
-
-
-
-
-*
-
- __ro__: The directory is shared read only; the client machine
-will not be able to write to it. This is the default.
-
-
-
-*
-*
-
- __rw__: The client machine will have read and write access to the
-directory.
-
-
-
-*
-*
-
- __no_root_squash__: By default, any file request made by user root
-on the client machine is treated as if it is made by user
-nobody on the server. (Excatly which UID the request is
-mapped to depends on the UID of user "nobody" on the server,
-not the client.) If no_root_squash is selected, then
-root on the client machine will have the same level of access
-to the files on the system as root on the server. This
-can have serious security implications, although it may be
-necessary if you want to perform any administrative work on
-the client machine that involves the exported directories.
-You should not specify this option without a good reason.
-
-
-
-*
-*
-
- __no_subtree_check__: If only part of a volume is exported, a
-routine called subtree checking verifies that a file that is
-requested from the client is in the appropriate part of the
-volume. If the entire volume is exported, disabling this check
-will speed up transfers.
-
-
-
-*
-*
-
- __sync__: By default, a Version 2 NFS server will tell a client
-machine that a file write is complete when NFS has finished
-handing the write over to the filesysytem; however, the file
-system may not sync it to the disk, even if the client makes
-a sync() call on the file system. The default behavior may
-therefore cause file corruption if the server reboots. This
-option forces the filesystem to sync to disk every time NFS
-completes a write operation. It slows down write times
-substantially but may be necessary if you are running NFS
-Version 2 in a production environment. Version 3 NFS has
-a commit operation that the client can call that
-actually will result in a disk sync on the server end.
-
-
-
-*
-
-
-
-
-
-
- Suppose we have two client machines, ''slave1'' and ''slave2'', that have IP
-addresses ''192.168..1'' and ''192.168..2'', respectively. We wish to share
-our software binaries and home directories with these machines.
-A typical setup for /etc/exports might look like this:
-
- /usr/local 192.168..1(ro) 192.168..2(ro)
-/home 192.168..1(rw) 192.168..2(rw)
-
-
-
-
- Here we are sharing /usr/local read-only to slave1 and slave2,
-because it probably contains our software and there may not be
-benefits to allowing slave1 and slave2 to write to it that outweigh
-security concerns. On the other hand, home directories need to be
-exported read-write if users are to save work on them.
-
-
-
- If you have a large installation, you may find that you have a bunch
-of computers all on the same local network that require access to
-your server. There are a few ways of simplifying references
-to large numbers of machines. First, you can give access to a range
-of machines at once by specifying a network and a netmask. For
-example, if you wanted to allow access to all the machines with IP
-addresses between ''192.168..'' and
-''192.168..255'' then you could have the entries:
-
- /usr/local 192.168../255.255.255.(ro)
-/home 192.168../255.255.255.(rw)
-
-
-
-
- See the Networking-Overview HOWTO
-for further information about how netmasks work, and you may also wish to
-look at the man pages for init and hosts.allow.
-
-
-
- Second, you can use NIS netgroups in your entry. To specify a
-netgroup in your exports file, simply prepend the name of the
-netgroup with an "@". See the NIS HOWTO
-for details on how netgroups work.
-
-
-
- Third, you can use wildcards such as ''*.foo.com'' or
-''192.168.'' instead of hostnames.
-
-
-
- However, you should keep in mind that any of these simplifications
-could cause a security risk if there are machines in your netgroup
-or local network that you do not trust completely.
-
-
-
- A few cautions are in order about what cannot (or should not) be
-exported. First, if a directory is exported, its parent and child
-directories cannot be exported if they are in the same filesystem.
-However, exporting both should not be necessary because listing the
-parent directory in the /etc/exports file will cause all underlying
-directories within that file system to be exported.
-
-
-
- Second, it is a poor idea to export a FAT or VFAT (i.e., MS-DOS or
-Windows 95/98) filesystem with NFS. FAT is not designed for use on a
-multi-user machine, and as a result, operations that depend on
-permissions will not work well. Moreover, some of the underlying
-filesystem design is reported to work poorly with NFS's expectations.
-
-
-
- Third, device or other special files may not export correctly to non-Linux
-clients. See Section 8 for details on particular operating systems.
-
-----
-!3.2.2. /etc/hosts.allow and /etc/hosts.deny
-
- These two files specify which computers on the network can use
-services on your machine. Each line of the file is an entry listing
-a service and a set of machines. When the server gets a request
-from a machine, it does the following:
-
-
-
-
-
-*
-
- It first checks hosts.allow to see if the machine
-matches a description listed in there. If it does, then the machine
-is allowed access.
-
-
-
-*
-*
-
- If the machine does not match an entry in hosts.allow, the
-server then checks hosts.deny to see if the client matches a
-listing in there. If it does then the machine is denied access.
-
-
-
-*
-*
-
- If the client matches no listings in either file, then it
-is allowed access.
-
-
-
-*
-
-
-
-
- In addition to controlling access to services handled by inetd (such
-as telnet and FTP), this file can also control access to NFS
-by restricting connections to the daemons that provide NFS services.
-Restrictions are done on a per-service basis.
-
-
-
-
- The first daemon to restrict access to is the portmapper. This daemon
-essentially just tells requesting clients how to find all the NFS
-services on the system. Restricting access to the portmapper is the
-best defense against someone breaking into your system through NFS
-because completely unauthorized clients won't know where to find the
-NFS daemons. However, there are two things to watch out for. First,
-restricting portmapper isn't enough if the intruder already knows
-for some reason how to find those daemons. And second, if you are
-running NIS, restricting portmapper will also restrict requests to NIS.
-That should usually be harmless since you usually want
-to restrict NFS and NIS in a similar way, but just be cautioned.
-(Running NIS is generally a good idea if you are running NFS, because
-the client machines need a way of knowing who owns what files on the
-exported volumes. Of course there are other ways of doing this such
-as syncing password files. See the NIS HOWTO for information on
-setting up NIS.)
-
-
-
-
- In general it is a good idea with NFS (as with most internet services)
-to explicitly deny access to hosts that you don't need to allow access
-to.
-
-
-
-
- The first step in doing this is to add the followng entry to
-/etc/hosts.deny:
-
-
-
-
-
- portmap:ALL
-
-
-
-
-
- Starting with nfs-utils .2., you can be a bit more careful by
-controlling access to individual daemons. It's a good precaution
-since an intruder will often be able to weasel around the portmapper.
-If you have a newer version of NFS-utils, add entries for each of the
-NFS daemons (see the next section to find out what these daemons are;
-for now just put entries for them in hosts.deny):
-
-
-
-
-
- lockd:ALL
-mountd:ALL
-rquotad:ALL
-statd:ALL
-
-
-
-
-
-
-Even if you have an older version of ''nfs-utils'', adding these entries
-is at worst harmless (since they will just be ignored) and at best
-will save you some trouble when you upgrade. Some sys admins choose
-to put the entry __ALL:ALL__ in the file /etc/hosts.deny,
-which causes any service that looks at these files to deny access to all
-hosts unless it is explicitly allowed. While this is more secure
-behavior, it may also get you in trouble when you are installing new
-services, you forget you put it there, and you can't figure out for
-the life of you why they won't work.
-
-
-
-
- Next, we need to add an entry to hosts.allow to give any hosts
-access that we want to have access. (If we just leave the above
-lines in hosts.deny then nobody will have access to NFS.) Entries
-in hosts.allow follow the format
-
-
-
-
-
- service: host [[or network/netmask] , host [[or network/netmask]
-
-
-
-
-
-
-
-
-
- Here, host is IP address of a potential client; it may be possible
-in some versions to use the DNS name of the host, but it is strongly
-deprecated.
-
-
-
-
- Suppose we have the setup above and we just want to allow access
-to ''slave1.foo.com'' and ''slave2.foo.com'',
-and suppose that the IP addresses of these machines are ''192.168..1''
-and ''192.168..2'', respectively. We could add the following entry to
-/etc/hosts.allow:
-
-
-
-
-
- portmap: 192.168..1 , 192.168..2
-
-
-
-
-
-
-
-
-
- For recent nfs-utils versions, we would also add the following
-(again, these entries are harmless even if they are not supported):
-
-
-
-
-
- lockd: 192.168..1 , 192.168..2
-rquotad: 192.168..1 , 192.168..2
-mountd: 192.168..1 , 192.168..2
-statd: 192.168..1 , 192.168..2
-
-
-
-
-
-
-
-
-
- If you intend to run NFS on a large number of machines in a local
-network, /etc/hosts.allow also allows for network/netmask style
-entries in the same manner as /etc/exports above.
-
-
-----
-!!3.3. Getting the services started
-!3.3.1. Pre-requisites
-
- The NFS server should now be configured and we can start it running.
-First, you will need to have the appropriate packages installed.
-This consists mainly of a new enough kernel and a new enough version
-of the nfs-utils package. See Section 2.4 if you are in doubt.
-
-
-
-
- Next, before you can start NFS, you will need to have TCP/IP
-networking functioning correctly on your machine. If you can use
-telnet, FTP, and so on, then chances are your TCP networking is fine.
-
-
-
-
- That said, with most recent Linux distributions you may be able to
-get NFS up and running simply by rebooting your machine, and the
-startup scripts should detect that you have set up your /etc/exports
-file and will start up NFS correctly. If you try this, see Section 3.4
-Verifying that NFS is running. If this does not work, or if
-you are not in a position to reboot your machine, then the following
-section will tell you which daemons need to be started in order to
-run NFS services. If for some reason nfsd was already running when
-you edited your configuration files above, you will have to flush
-your configuration; see Section 3.5 for details.
-
-
-----
-!3.3.2. Starting the Portmapper
-
- NFS depends on the portmapper daemon, either called __portmap__ or
-__rpc.portmap__. It will need to be started first. It should be
-located in /sbin but is sometimes in /usr/sbin.
-Most recent Linux distributions start this daemon in the boot scripts, but it is
-worth making sure that it is running before you begin working with
-NFS (just type __ps aux | grep portmap__).
-
-
-----
-!3.3.3. The Daemons
-
- NFS serving is taken care of by five daemons: rpc.nfsd, which does
-most of the work; rpc.lockd and rpc.statd, which handle file locking;
-rpc.mountd, which handles the initial mount requests, and
-rpc.rquotad, which handles user file quotas on exported volumes.
-Starting with 2.2.18, lockd is called by nfsd upon demand, so you do
-not need to worry about starting it yourself. statd will need to be
-started separately. Most recent Linux distributions will
-have startup scripts for these daemons.
-
-
-
-
- The daemons are all part of the nfs-utils package, and may be either
-in the /sbin directory or the /usr/sbin directory.
-
-
-
-
- If your distribution does not include them in the startup scripts,
-then then you should add them, configured to start in the following
-order:
-
-
-
-
-
-rpc.portmaprpc.mountd, rpc.nfsdrpc.statd, rpc.lockd (if necessary), rpc.rquotad
-
-
-
-
-
-
-
-
- The nfs-utils package has sample startup scripts for !RedHat and
-Debian. If you are using a different distribution, in general you
-can just copy the !RedHat script, but you will probably have to take
-out the line that says:
-
- . ../init.d/functions
-
-to avoid getting error messages.
-
-
-----
-!!3.4. Verifying that NFS is running
-
- To do this, query the portmapper with the command __rpcinfo -p__ to
-find out what services it is providing. You should get something
-like this:
-
- program vers proto port
-100000 2 tcp 111 portmapper
-100000 2 udp 111 portmapper
-100011 1 udp 749 rquotad
-100011 2 udp 749 rquotad
-100005 1 udp 759 mountd
-100005 1 tcp 761 mountd
-100005 2 udp 764 mountd
-100005 2 tcp 766 mountd
-100005 3 udp 769 mountd
-100005 3 tcp 771 mountd
-100003 2 udp 2049 nfs
-100003 3 udp 2049 nfs
-300019 1 tcp 830 amd
-300019 1 udp 831 amd
-100024 1 udp 944 status
-100024 1 tcp 946 status
-100021 1 udp 1042 nlockmgr
-100021 3 udp 1042 nlockmgr
-100021 4 udp 1042 nlockmgr
-100021 1 tcp 1629 nlockmgr
-100021 3 tcp 1629 nlockmgr
-100021 4 tcp 1629 nlockmgr
-
-
-
-
-
- This says that we have NFS versions 2 and 3, rpc.statd version 1,
-network lock manager (the service name for rpc.lockd) versions 1, 3,
-and 4. There are also different service listings depending on
-whether NFS is travelling over TCP or UDP. Linux systems use UDP
-by default unless TCP is explicitly requested; however other OSes
-such as Solaris default to TCP.
-
-
-
-
- If you do not at least see a line that says "portmapper", a line
-that says "nfs", and a line that says "mountd" then you will need
-to backtrack and try again to start up the daemons (see Section 7,
-Troubleshooting, if this still doesn't work).
-
-
-
-
- If you do see these services listed, then you should be ready to
-set up NFS clients to access files from your server.
-
-
-----
-!!3.5. Making changes to /etc/exports later on
-
- If you come back and change your /etc/exports file, the changes you
-make may not take effect immediately. You should run the command
-__exportfs -ra__ to force nfsd to re-read the /etc/exports
- file. If you can't find the __exportfs__ command, then you can kill nfsd with the
-__ -HUP__ flag (see the man pages for kill for details).
-
-
-
-
- If that still doesn't work, don't forget to check hosts.allow to
-make sure you haven't forgotten to list any new client machines
-there. Also check the host listings on any firewalls you may have
-set up (see Section 7 for more details on firewalls
-and NFS).
-
-
-----
-!!!4. Setting up an NFS Client
-!!4.1. Mounting remote directories
-
- Before beginning, you should double-check to make sure your mount
-program is new enough (version 2.10m if you want to use Version 3
-NFS), and that the client machine supports NFS mounting, though most
-standard distributions do. If you are using a 2.2 or later kernel
-with the /proc filesystem you can check the latter by reading the
-file /proc/filesystems and making sure there is a line containing
-nfs. If not, you will need to build (or download) a kernel that has
-NFS support built in.
-
-
-
-
- To begin using machine as an NFS client, you will need the portmapper
-running on that machine, and to use NFS file locking, you will
-also need rpc.statd and rpc.lockd
-running on both the client and the server. Most recent distributions
-start those services by default at boot time; if yours doesn't, see
-Section 3.2 for information on how to start them up.
-
-
-
-
- With portmapper, lockd, and statd running, you should now be able to
-mount the remote directory from your server just the way you mount
-a local hard drive, with the mount command. Continuing our example
-from the previous section, suppose our server above is called
-''master.foo.com'',and we want to mount the /home directory on
-''slave1.foo.com''. Then, all we have to do, from the root prompt on
-''slave1.foo.com'', is type:
-
- # mount master.foo.com:/home /mnt/home
-
-and the directory /home on master will appear as the directory
-/mnt/home on ''slave1''.
-
-
-
-
- If this does not work, see the Troubleshooting section (Section 7).
-
-
-
-
- You can get rid of the file system by typing
-
- # umount /mnt/home
-
-just like you would for a local file system.
-
-
-----
-!!4.2. Getting NFS File Systems to Be Mounted at Boot Time
-
- NFS file systems can be added to your /etc/fstab file the same way
-local file systems can, so that they mount when your system starts
-up. The only difference is that the file system type will be
-set to __nfs__ and the dump and fsck order (the last two entries) will
-have to be set to zero. So for our example above, the entry in
-/etc/fstab would look like:
-
- # device mountpoint fs-type options dump fsckorder
-...
-master.foo.com:/home /mnt nfs rw 0
-...
-
-
-
-
-
- See the man pages for fstab if you are unfamiliar
-with the syntax of this file. If you are using an automounter such as
-amd or autofs, the options in the corresponding fields of your mount
-listings should look very similar if not identical.
-
-
-
-
- At this point you should have NFS working, though a few tweaks
-may still be necessary to get it to work well. You should also
-read Section 6 to be sure your setup is reasonably secure.
-
-
-----
-!!4.3. Mount options
-!4.3.1. Soft vs. Hard Mounting
-
- There are some options you should consider adding at once. They
-govern the way the NFS client handles a server crash or network
-outage. One of the cool things about NFS is that it can handle this
-gracefully. If you set up the clients right. There are two distinct
-failure modes:
-
-
-
-
- ; __soft__:
-
- If a file request fails, the NFS client will report an
-error to the process on the client machine requesting the file
-access. Some programs can handle this with composure, most
-won't. We do not recommend using this setting; it is a recipe
-for corrupted files and lost data. You should especially not
-use this for mail disks --- if you value your mail, that is.
-
-
-; __hard__:
-
- The program accessing a file on a NFS mounted file system
-will hang when the server crashes. The process cannot be
-interrupted or killed (except by a "sure kill") unless you also
-specify intr. When the NFS server is back online the program will
-continue undisturbed from where it was. We recommend using hard,
-intr on all NFS mounted file systems.
-
-
-
-
-
-
-
- Picking up the from previous example, the fstab entry would now
-look like:
-
- # device mountpoint fs-type options dump fsckord
-...
-master.foo.com:/home /mnt/home nfs rw,hard,intr 0
-...
-
-
-
-----
-!4.3.2. Setting Block Size to Optimize Transfer Speeds
-
- The __rsize__ and __wsize__ mount
-options specify the size of the chunks of data that the client and
-server pass back and forth to each other.
-
-
-
-
- The defaults may be too big or to small; there is no size that works
-well on all or most setups. On the one hand, some combinations of
-Linux kernels and network cards (largely on older machines) cannot
-handle blocks that large. On the other hand, if they can handle
-larger blocks, a bigger size might be faster.
-
-
-
-
- Getting the block size right is an important factor in performance and
-is a must if you are planning to use the NFS server in a production
-environment. See Section 5 for details.
-
-
-----
-!!!5. Optimizing NFS Performance
-
- Getting network settings right can improve NFS performance many times
-over -- a tenfold increase in transfer speeds is not unheard of.
-The most important things to get right are the __rsize__
-and __wsize__ __mount__ options. Other factors listed below
-may affect people with particular hardware setups.
-
-
-----
-!!5.1. Setting Block Size to Optimize Transfer Speeds
-
- The __rsize__ and __wsize__
-__mount__ options specify the size of the chunks of data
-that the client and server pass back and forth to each other. If no
-__rsize__ and __wsize__ options
-are specified, the default varies by which version of NFS we are using.
-4096 bytes is the most common default, although for TCP-based mounts
-in 2.2 kernels, and for all mounts beginning with 2.4 kernels, the
-server specifies the default block size.
-
-
-
-
- The defaults may be too big or too small. On the one hand, some
-combinations of Linux kernels and network cards (largely on older
-machines) cannot handle blocks that large. On the other hand, if they
-can handle larger blocks, a bigger size might be faster.
-
-
-
-
- So we'll want to experiment and find an rsize and wsize that works
-and is as fast as possible. You can test the speed of your options
-with some simple commands.
-
-
-
-
- The first of these commands transfers 16384 blocks of 16k each from
-the special file /dev/zero (which if you read it
-just spits out zeros _really_ fast) to the mounted partition. We will
-time it to see how long it takes. So, from the client machine, type:
-
- # time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
-
-
-
-
-
- This creates a 256Mb file of zeroed bytes. In general, you should
-create a file that's at least twice as large as the system RAM
-on the server, but make sure you have enough disk space! Then read
-back the file into the great black hole on the client machine
-(/dev/null) by typing the following:
-
- # time dd if=/mnt/home/testfile of=/dev/null bs=16k
-
-
-
-
-
- Repeat this a few times and average how long it takes. Be sure to
-unmount and remount the filesystem each time (both on the client and,
-if you are zealous, locally on the server as well), which should clear
-out any caches.
-
-
-
-
- Then unmount, and mount again with a larger and smaller block size.
-They should probably be multiples of 1024, and not larger than
-8192 bytes since that's the maximum size in NFS version 2. (Though
-if you are using Version 3 you might want to try up to 32768.)
-Wisdom has it that the block size should be a power of two since most
-of the parameters that would constrain it (such as file system block
-sizes and network packet size) are also powers of two. However, some
-users have reported better successes with block sizes that are not
-powers of two but are still multiples of the file system block size
-and the network packet size.
-
-
-
-
- Directly after mounting with a larger size, cd into the mounted
-file system and do things like ls, explore the fs a bit to make
-sure everything is as it should. If the rsize/wsize is too large
-the symptoms are very odd and not 100% obvious. A typical symptom
-is incomplete file lists when doing 'ls', and no error messages.
-Or reading files failing mysteriously with no error messages. After
-establishing that the given rsize/wsize works you can do the speed
-tests again. Different server platforms are likely to have different
-optimal sizes. SunOS and Solaris is reputedly a lot faster with 4096
-byte blocks than with anything else.
-
-
-
-
- ''Remember to edit /etc/fstab to reflect the rsize/wsize you found.''
-
-
-----
-!!5.2. Packet Size and Network Drivers
-
- There are many shoddy network drivers available for Linux,
-including for some fairly standard cards.
-
-
-
-
- Try pinging back and forth between the two machines with large
-packets using the -f and -s
-options with __ping__ (see __man ping__)
-for more details and see if a lot of packets get or if they
-take a long time for a reply. If so, you may have a problem
-with the performance of your network card.
-
-
-
-
- To correct such a problem, you may wish to reconfigure the packet
-size that your network card uses. Very often there is a constraint
-somewhere else in the network (such as a router) that causes a
-smaller maximum packet size between two machines than what the
-network cards on the machines are actually capable of. TCP should
-autodiscover the appropriate packet size for a network, but UDP
-will simply stay at a default value. So determining the appropriate
-packet size is especially important if you are using NFS over UDP.
-
-
-
-
- You can test for the network packet size using the tracepath command:
-From the client machine, just type __tracepath [[server] 2049__
-and the path MTU should be reported at the bottom. You can then set the
-MTU on your network card equal to the path MTU, by using the MTU option
-to __ifconfig__, and see if fewer packets get dropped.
-See the __ifconfig__ man pages for details on how to reset the MTU.
-
-
-----
-!!5.3. Number of Instances of NFSD
-
- Most startup scripts, Linux and otherwise, start 8 instances of nfsd.
-In the early days of NFS, Sun decided on this number as a rule of thumb,
-and everyone else copied. There are no good measures of how many
-instances are optimal, but a more heavily-trafficked server may require
-more. If you are using a 2.4 or higher kernel and you want to see how
-heavily each nfsd thread is being used, you can look at the file
-/proc/net/rpc/nfsd. The last ten numbers on the
-''th'' line in that file indicate the number of seconds
-that the thread usage was at that percentage of the maximum allowable.
-If you have a large number in the top three deciles, you may wish to
-increase the number of __nfsd__ instances. This is done
-upon starting __nfsd__ using the number of instances as
-the command line option. See the __nfsd__ man page for
-more information.
-
-
-----
-!!5.4. Memory Limits on the Input Queue
-
- On 2.2 and 2.4 kernels, the socket input queue, where requests
-sit while they are currently being processed, has a small default
-size limit of 64k. This means that if you are running 8 instances of
-__nfsd__, each will only have 8k to store requests while it processes
-them.
-
-
-
-
- You should consider increasing this number to at least 256k for __nfsd__.
-This limit is set in the proc file system using the files
-/proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max.
-It can be increased in three steps; the following method is a bit of
-a hack but should work and should not cause any problems:
-
-
-
-
-
-
-
-
-
-#
-
-Increase the size listed in the file:
-
- echo 262144 b /proc/sys/net/core/rmem_default
-echo 262144 b /proc/sys/net/core/rmem_max
-
-
-
-
-#
-#
-
-
-Restart __nfsd__, e.g., type __/etc/rc.d/init.d/nfsd restart__ on Red Hat
-
-
-
-#
-#
-
- Return the size limits to their normal size in case other kernel systems depend on it:
-
-
-echo 65536 b /proc/sys/net/core/rmem_default
-echo 65536 b /proc/sys/net/core/rmem_max
-
-
-
-
-
- '' Be sure to perform this last step because machines have been reported
-to crash if these values are left changed for long periods of time.
-''
-
-
-
-#
-
-----
-!!5.5. Overflow of Fragmented Packets
-
- The NFS protocol uses fragmented UDP packets. The kernel has
-a limit of how many fragments of incomplete packets it can
-buffer before it starts throwing away packets. With 2.2 kernels
-that support the /proc filesystem, you can
-specify how many by editing the files
-/proc/sys/net/ipv4/ipfrag_high_thresh and
-/proc/sys/net/ipv4/ipfrag_low_thresh.
-
-
-
-
- Once the number of unprocessed, fragmented packets reaches the
-number specified by __ipfrag_high_thresh__ (in bytes), the kernel
-will simply start throwing away fragmented packets until the number
-of incomplete packets reaches the number specified
-by __ipfrag_low_thresh__. (With 2.2 kernels, the default is usually 256K).
-This will look like packet loss, and if the high threshold is
-reached your server performance drops a lot.
-
-
-
-
- One way to monitor this is to look at the field IP: !ReasmFails in the
-file /proc/net/snmp; if it goes up too quickly during heavy file
-activity, you may have problem. Good alternative values for
-__ipfrag_high_thresh__ and __ipfrag_low_thresh__
-have not been reported; if you have a good experience with a
-particular value, please let the maintainers and development team know.
-
-
-----
-!!5.6. Turning Off Autonegotiation of NICs and Hubs
-
- Sometimes network cards will auto-negotiate badly with
-hubs and switches and this can have strange effects.
-Moreover, hubs may lose packets if they have different
-ports running at different speeds. Try playing around
-with the network speed and duplex settings.
-
-
-----
-!!5.7. Non-NFS-Related Means of Enhancing Server Performance
-
- Offering general guidelines for setting up a well-functioning
-file server is outside the scope of this document, but a few
-hints may be worth mentioning: First, RAID 5 gives you good
-read speeds but lousy write speeds; consider RAID 1/0 if both
-write speed and redundancy are important. Second, using a
-journalling filesystem will drastically reduce your reboot
-time in the event of a system crash; as of this writing, ext3
-(ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/) was the only
-journalling filesystem that worked correctly with
-NFS version 3, but no doubt that will change soon.
-In particular, it looks like Reiserfs
-should work with NFS version 3 on 2.4 kernels, though not yet
-on 2.2 kernels. Finally, using an automounter (such as autofs
-or amd) may prevent hangs if you cross-mount files
-on your machines (whether on purpose or by oversight) and one of those
-machines goes down. See the
-Automount Mini-HOWTO
-for details.
-
-
-----
-!!!6. Security and NFS
-
- This list of security tips and explanations will not make your site
-completely secure. ''NOTHING'' will make your site completely secure. This
-may help you get an idea of the security problems with NFS. This is not
-a comprehensive guide and it will always be undergoing changes. If you
-have any tips or hints to give us please send them to the HOWTO
-maintainer.
-
-
-
-
- If you're on a network with no access to the outside world (not even a
-modem) and you trust all the internal machines and all your users then
-this section will be of no use to you. However, its our belief that
-there are relatively few networks in this situation so we would suggest
-reading this section thoroughly for anyone setting up NFS.
-
-
-
-
- There are two steps to file/mount access in NFS. The first step is mount
-access. Mount access is achieved by the client machine attempting to
-attach to the server. The security for this is provided by the
-/etc/exports file. This file lists the names or ip addresses for machines
-that are allowed to access a share point. If the client's ip address
-matches one of the entries in the access list then it will be allowed to
-mount. This is not terribly secure. If someone is capable of spoofing or
-taking over a trusted address then they can access your mount points. To
-give a real-world example of this type of "authentication": This is
-equivalent to someone introducing themselves to you and you believe they
-are who they claim to be because they are wearing a sticker that says
-"Hello, My Name is ...."
-
-
-
-
- The second step is file access. This is a function of normal file system
-access controls and not a specialized function of NFS. Once the drive is
-mounted the user and group permissions on the files take over access
-control.
-
-
-
-
- An example: bob on the server maps to the UserID 9999. Bob
-makes a file on the server that is only accessible the user (0600 in
-octal). A client is allowed to mount the drive where the file is stored.
-On the client mary maps to UserID 9999. This means that the client
-user mary can access bob's file that is marked as only accessible by him.
-It gets worse, if someone has root on the client machine they can
-__su - [[username]__ and become ANY user. NFS will be none
-the wiser.
-
-
-
-
- Its not all terrible. There are a few measures you can take on the server
-to offset the danger of the clients. We will cover those shortly.
-
-
-
-
- If you don't think the security measures apply to you, you're probably
-wrong. In Section 6.1 we'll cover securing the portmapper,
-server and client security in Section 6.2 and Section 6.3 respectively.
-Finally, in Section 6.4 we'll briefly talk about proper firewalling for
-your nfs server.
-
-
-
-
- Finally, it is critical that all of your nfs daemons and client programs
-are current. If you think that a flaw is too recently announced for it to
-be a problem for you, then you've probably already been compromised.
-
-
-
-
- A good way to keep up to date on security alerts is to subscribe to the
-bugtraq mailinglists. You can read up on how to subscribe and various
-other information about bugtraq here:
-http://www.securityfocus.com/forums/bugtraq/faq.html
-
-
-
-
- Additionally searching for ''NFS'' at
-securityfocus.com's search engine will
-show you all security reports pertaining to NFS.
-
-
-
-
- You should also regularly check CERT advisories. See the CERT web page
-at www.cert.org.
-
-
-----
-!!6.1. The portmapper
-
- The portmapper keeps a list of what services are running on what ports.
-This list is used by a connecting machine to see what ports it wants to
-talk to access certain services.
-
-
-
-
-
-The portmapper is not in as bad a shape as a few years ago but it is
-still a point of worry for many sys admins. The portmapper, like NFS and
-NIS, should not really have connections made to it outside of a trusted
-local area network. If you have to expose them to the outside world -
-be careful and keep up diligent monitoring of those systems.
-
-
-
-
- Not all Linux distributions were created equal. Some seemingly up-to-
-date distributions do not include a securable portmapper.
-The easy way to check if your portmapper is good or not is to run
-''strings(1)'' and see if it reads the relevant files, /etc/hosts.deny and
-/etc/hosts.allow. Assuming your portmapper is /sbin/portmap you can
-check it with this command:
-
- strings /sbin/portmap | grep hosts.
-
-
-
-
-
- On a securable machine it comes up something like this:
-
- /etc/hosts.allow
-/etc/hosts.deny
-@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
-@(#) hosts_access.c 1.21 97/02/12 02:13:22
-
-
-
-
-
- First we edit /etc/hosts.deny. It should contain the line
-
-
-
-
-
- portmap: ALL
-
-
-
-
-
- which will deny access to everyone. While it is closed run:
-
- rpcinfo -p
-
-just to check that your portmapper really reads and obeys
-this file. Rpcinfo should give no output, or possibly an error message.
-The files /etc/hosts.allow and /etc/hosts.deny
-take effect immediately after you save them. No daemon needs to be restarted.
-
-
-
-
- Closing the portmapper for everyone is a bit drastic, so we open it
-again by editing /etc/hosts.allow. But first
-we need to figure out what to put in it. It should basically list
-all machines that should have access to your portmapper. On a run of
-the mill Linux system there are very few machines that need any access
-for any reason. The portmapper administers __nfsd__,
-__mountd__, __ypbind__/__ypserv__,
-__pcnfsd__, and 'r' services like __ruptime__ and __rusers__.
-Of these only __nfsd__, __mountd__,
-__ypbind__/__ypserv__ and perhaps
-__pcnfsd__ are of any consequence. All machines that need
-to access services on your machine should be allowed to do that. Let's
-say that your machine's address is ''192.168..254'' and
-that it lives on the subnet ''192.168..'', and that all
-machines on the subnet should have access to it (those are terms introduced
-by the Networking-Overview-HOWTO,
-go back and refresh your memory if you need to). Then we write:
-
- portmap: 192.168../255.255.255.
-
-in /etc/hosts.allow. This is the same as the network
-address you give to route and the subnet mask you give to __ifconfig__. For the
-device eth0 on this machine __ifconfig__ should show:
-
-
-
-
-
- ...
-eth0 Link encap:Ethernet HWaddr 00:60:8C:96:D5:56
-inet addr:192.168..254 Bcast:192.168..255 Mask:255.255.255.
-UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
-RX packets:360315 errors:0 dropped:0 overruns:
-TX packets:179274 errors:0 dropped:0 overruns:
-Interrupt:10 Base address:0x320
-...
-
-and __netstat -rn__ should show:
-
- Kernel routing table
-Destination Gateway Genmask Flags Metric Ref Use Iface
-...
-192.168..0 ...0 255.255.255.0 U 0 0 174412 eth0
-...
-
-(Network address in first column).
-
-
-
-
- The /etc/hosts.deny and /etc/hosts.allow files are
-described in the manual pages of the same names.
-
-
-
-
- '' IMPORTANT: Do not put anything but IP NUMBERS in the portmap lines of
-these files. Host name lookups can indirectly cause portmap activity
-which will trigger host name lookups which can indirectly cause
-portmap activity which will trigger...
-''
-
-
-
-
- Versions .2.0 and higher of the nfs-utils package also use the
-hosts.allow and hosts.deny
-files, so you should put in entries for __lockd__,
-__statd__, __mountd__, and
-__rquotad__ in these files too.
-
-
-
-
- The above things should make your server tighter. The only remaining
-problem (Yeah, right!) is someone breaking root (or boot MS-DOS) on a
-trusted machine and using that privilege to send requests from a
-secure port as any user they want to be.
-
-
-----
-!!6.2. Server security: nfsd and mountd
-
- On the server we can decide that we don't want to trust the client's
-root account. We can do that by using the __root_squash__ option in
-/etc/exports:
-
- /home slave1(rw,root_squash)
-
-
-
-
-
- This is, in fact, the default. It should always be turned on unless you
-have a VERY good reason to turn it off. To turn it off use the
-__no_root_squash__ option.
-
-
-
-
- Now, if a user with ''UID'' 0 (i.e., root's user ID number)
-on the client attempts to access (read, write, delete) the file system,
-the server substitutes the ''UID'' of the server's 'nobody'
-account. Which means that the root user on the client can't access or
-change files that only root on the server can access or change. That's
-good, and you should probably use __root_squash__ on
-all the file systems you export. "But the root user on the client can
-still use __su__ to become any other user and
-access and change that users files!" say you. To which the answer is:
-Yes, and that's the way it is, and has to be with Unix and NFS. This
-has one important implication: All important binaries and files should be
-owned by root, and not bin or other non-root account, since the only
-account the clients root user cannot access is the servers root
-account. In the ''exports(5)'' man page there are several other squash
-options listed so that you can decide to mistrust whomever you (don't)
-like on the clients.
-
-
-
-
- The TCP ports 1-1024 are reserved for root's use (and therefore sometimes
-referred to as "secure ports") A non-root user cannot bind these ports.
-Adding the secure option to an /etc/exports entry forces it to run on a
-port below 1024, so that a malicious non-root user cannot come along and
-open up a spoofed NFS dialogue on a non-reserved port. This option is set
-by default.
-
-
-----
-!!6.3. Client Security
-!6.3.1. The nosuid mount option
-
- On the client we can decide that we don't want to trust the server too
-much a couple of ways with options to mount. For example we can
-forbid suid programs to work off the NFS file system with the nosuid
-option. Some unix programs, such as passwd, are called "suid" programs:
-They set the id of the person running them to whomever is the owner of
-the file. If a file is owned by root and is suid, then the program will
-execute as root, so that they can perform operations (such as writing to
-the password file) that only root is allowed to do. Using the nosuid
-option is a good idea and you should consider using this with all NFS
-mounted disks. It means that the server's root user cannot make a suid-root
-program on the file system, log in to the client as a normal user
-and then use the suid-root program to become root on the client too.
-One could also forbid execution of files on the mounted file system
-altogether with the __noexec__ option.
-But this is more likely to be impractical than nosuid since a file
-system is likely to at least contain some scripts or programs that need
-to be executed.
-
-
-----
-!6.3.2. The broken_suid mount option
-
- Some older programs (__xterm__ being one of them) used to rely on the idea
-that root can write everywhere. This is will break under new kernels on
-NFS mounts. The security implications are that programs that do this
-type of suid action can potentially be used to change your apparent uid
-on nfs servers doing uid mapping. So the default has been to disable this
-__broken_suid__ in the linux kernel.
-
-
-
-
- The long and short of it is this: If you're using an old linux
-distribution, some sort of old suid program or an older unix of some
-type you ''might'' have to mount from your clients with the
-__broken_suid__ option to __mount__.
-However, most recent unixes and linux distros have __xterm__ and such programs
-just as a normal executable with no suid status, they call programs to do their setuid work.
-
-
-
-
- You enter the above options in the options column, with the __rsize__ and
-__wsize__, separated by commas.
-
-
-----
-!6.3.3. Securing portmapper, rpc.statd, and rpc.lockd on the client
-
- In the current (2.2.18+) implementation of nfs, full file locking is
-supported. This means that __rpc.statd__ and __rpc.lockd__
-must be running on the client in order for locks to function correctly.
-These services require the portmapper to be running. So, most of the
-problems you will find with nfs on the server you may also be plagued with
-on the client. Read through the portmapper section above for information on
-securing the portmapper.
-
-
-----
-!!6.4. NFS and firewalls (ipchains and netfilter)
-
- IPchains (under the 2.2.X kernels) and netfilter (under the 2.4.x
-kernels) allow a good level of security - instead of relying on the
-daemon (or in this case the tcp wrapper) to determine who can connect,
-the connection attempt is allowed or disallowed at a lower level. In
-this case you canstop the connection much earlier and more globaly which
-can protect you from all sorts of attacks.
-
-
-
-
- Describing how to set up a Linux firewall is well beyond the scope of
-this document. Interested readers may wish to read the Firewall-HOWTO
-or the IPCHAINS-HOWTO.
-For users of kernel 2.4 and above you might want to visit the netfilter webpage at:
-http://netfilter.filewatcher.org.
-If you are already familiar with the workings of ipchains or netfilter
-this section will give you a few tips on how to better setup your
-firewall to work with NFS.
-
-
-
-
- A good rule to follow for your firewall configuration is to deny all, and
-allow only some - this helps to keep you from accidentally allowing more
-than you intended.
-
-
-
-
- Ports to be concerned with:
-
-
-
-
-
-#
-
-The portmapper is on 111. (tcp and udp)
-
-
-#
-#
-
- nfsd is on 2049 and it can be TCP and UDP. Although NFS over TCP
-is currently experimental on the server end and you will usually
-just see UDP on the server, using TCP is quite stable on the
-client end.
-
-
-
-#
-#
-
- __mountd__, __lockd__, and __statd__
-float around (which is why we need the portmapper to begin with) - this causes
-problems. You basically have two options to deal with it:
-
-
-
-
-
-##
-
- You more can more or less do a deny all on connecting ports
-but explicitly allow most ports certain ips.
-
-
-
-##
-##
-
- More recent versions of these utilities have a "-p" option
-that allows you to assign them to a certain port. See the
-man pages to be sure if your version supports this. You can
-then allow access to the ports you have specified for your
-NFS client machines, and seal off all other ports, even for
-your local network.
-
-
-
-##
-
-
-
-#
-
-
-
-
- Using IPCHAINS, a simply firewall using the first option would look
-something like this:
-
- ipchains -A input -f -j ACCEPT
-ipchains -A input -s trusted.net.here/trusted.netmask -d host.ip/255.255.255.255 -j ACCEPT
-ipchains -A input -s /0 -d /0 -p 6 -j DENY -y -l
-ipchains -A input -s /0 -d /0 -p 17 -j DENY -l
-
-
-
-
-
- The equivalent set of commands in netfilter (the firewalling tool in 2.4) is:
-
-
-iptables -A INPUT -f -j ACCEPT
-iptables -A INPUT -s trusted.net.here/trusted.netmask -d \
-host.ip/255.255.255.255 -j ACCEPT
-iptables -A INPUT -s /0 -d /0 -p 6 -j DENY --syn --log-level 5
-iptables -A INPUT -s /0 -d /0 -p 17 -j DENY --log-level 5
-
-
-
-
-
- The first line says to accept all packet fragments (except the first
-packet fragment which will be treated as a normal packet). In theory
-no packet will pass through until it is reassembled, and it won't be
-reassembled unless the first packet fragment is passed. Of course
-there are attacks that can be generated by overloading a machine
-with packet fragments. But NFS won't work correctly unless you
-let fragments through. See Section 7 for details.
-
-
-
-
- The other three lines say trust your local networks and deny and log
-everything else. It's not great and more specific rules pay off, but
-more specific rules are outside of the scope of this discussion.
-
-
-
-
- Some pointers if you'd like to be more paranoid or strict about your
-rules. If you choose to reset your firewall rules each time __statd__,
-__rquotad__, __mountd__ or __lockd__
-move (which is possible) you'll want to make sure you allow fragments to
-your nfs server FROM your nfs client(s). If you don't you will get some very
-interesting reports from the kernel regarding packets being denied. The messages
-will say that a packet from port 65535 on the client to 65535 on the server
-is being denied. Allowing fragments will solve this.
-
-
-----
-!!6.5. Summary
-
- If you use the hosts.allow, hosts.deny,
-root_squash, __nosuid__ and privileged
-port features in the portmapper/nfs software you avoid many of the
-presently known bugs in nfs and can almost feel secure about that at
-least. But still, after all that: When an intruder has access to your
-network, s/he can make strange commands appear in your .forward or
-read your mail when /home or /var/mail is
-NFS exported. For the same reason, you should never access your PGP private key
-over nfs. Or at least you should know the risk involved. And now you know a bit
-of it.
-
-
-
-
- NFS and the portmapper makes up a complex subsystem and therefore it's
-not totally unlikely that new bugs will be discovered, either in the
-basic design or the implementation we use. There might even be holes
-known now, which someone is abusing. But that's life.
-
-
-----
-!!!7. Troubleshooting
-
-
-
-
-
- This is intended as a step-by-step guide to what to do when
-things go wrong using NFS. Usually trouble first rears its
-head on the client end, so this diagnostic will begin there.
-
-
-
-
-
-
-----
-!!7.1. Unable to See Files on a Mounted File System
-
- First, check to see if the file system is actually mounted.
-There are several ways of doing this. The most reliable
-way is to look at the file /proc/mounts,
-which will list all mounted filesystems and give details about them. If
-this doesn't work (for example if you don't have the /proc
-filesystem compiled into your kernel), you can type
-'mount -f' although you get less information.
-
-
-
-
- If the file system appears to be mounted, then you may
-have mounted another file system on top of it (in which
-case you should unmount and remount both volumes), or you
-may have exported the file system on the server before you
-mounted it there, in which case NFS is exporting the underlying
-mount point (if so then you need to restart NFS on the
-server).
-
-
-
-
- If the file system is not mounted, then attempt to mount it.
-If this does not work, see ''Symptom 3''.
-
-
-----
-!!7.2. File requests hang or timeout waiting for access to the file.
-
- This usually means that the client is unable to communicate with
-the server. See ''Symptom 3'' letter b.
-
-
-----
-!!7.3. Unable to mount a file system
-
- There are two common errors that mount produces when
-it is unable to mount a volume. These are:
-
-
-
-
-
-#
-
- failed, reason given by server: Permission denied
-
-
-
-
-
-This means that the server does not recognize that you
-have access to the volume.
-
-
-
-
-
-
-
-##
-
- Check your /etc/exports file and make sure that the
-volume is exported and that your client has the right
-kind of access to it. For example, if a client only
-has read access then you have to mount the volume
-with the ro option rather than the rw option.
-
-
-
-##
-##
-
- Make sure that you have told NFS to register any
-changes you made to /etc/exports since starting nfsd
-by running the exportfs command. Be sure to type
-__exportfs -ra__ to be extra certain that the exports are
-being re-read.
-
-
-
-##
-##
-
- Check the file /proc/fs/nfs/exports and make sure the
-volume and client are listed correctly. (You can also
-look at the file /var/lib/nfs/xtab for an unabridged
-list of how all the active export options are set.) If they
-are not, then you have not re-exported properly. If they
-are listed, make sure the server recognizes your
-client as being the machine you think it is. For
-example, you may have an old listing for the client
-in /etc/hosts that is throwing off the server, or
-you may not have listed the client's complete address
-and it may be resolving to a machine in a different
-domain. Try to ping the client from the server, and try
-to ping the server from the client. If this doesn't work,
-or if there is packet loss, you may have lower-level network
-problems.
-
-
-
-##
-#
-#
-
-RPC: Program Not Registered (or another "RPC" error):
-
-
-
- This means that the client does not detect NFS running
-on the server. This could be for several reasons.
-
-
-
-
-
-
-
-##
-
- First, check that NFS actually is running on the
-server by typing __rpcinfo -p__ on the server.
-You should see something like this:
-
- program vers proto port
-100000 2 tcp 111 portmapper
-100000 2 udp 111 portmapper
-100011 1 udp 749 rquotad
-100011 2 udp 749 rquotad
-100005 1 udp 759 mountd
-100005 1 tcp 761 mountd
-100005 2 udp 764 mountd
-100005 2 tcp 766 mountd
-100005 3 udp 769 mountd
-100005 3 tcp 771 mountd
-100003 2 udp 2049 nfs
-100003 3 udp 2049 nfs
-300019 1 tcp 830 amd
-300019 1 udp 831 amd
-100024 1 udp 944 status
-100024 1 tcp 946 status
-100021 1 udp 1042 nlockmgr
-100021 3 udp 1042 nlockmgr
-100021 4 udp 1042 nlockmgr
-100021 1 tcp 1629 nlockmgr
-100021 3 tcp 1629 nlockmgr
-100021 4 tcp 1629 nlockmgr
-
-This says that we have NFS versions 2 and 3, rpc.statd
-version 1, network lock manager (the service name for
-rpc.lockd) versions 1, 3, and 4. There are also different
-service listings depending on whether NFS is travelling over
-TCP or UDP. UDP is usually (but not always) the default
-unless TCP is explicitly requested.
-
-
-
-
- If you do not see at least portmapper, nfs, and mountd, then
-you need to restart NFS. If you are not able to restart
-successfully, proceed to ''Symptom 9''.
-
-
-
-##
-##
-
- Now check to make sure you can see it from the client.
-On the client, type __rpcinfo -p [[server]__ where
-__[[server]__ is the DNS name or IP address of your server.
-
-
-
-
- If you get a listing, then make sure that the type
-of mount you are trying to perform is supported. For
-example, if you are trying to mount using Version 3
-NFS, make sure Version 3 is listed; if you are trying
-to mount using NFS over TCP, make sure that is
-registered. (Some non-Linux clients default to TCP).
-See man rpcinfo for more details on how
-to read the output. If the type of mount you are
-trying to perform is not listed, try a different
-type of mount.
-
-
-
-
- If you get the error No Remote Programs Registered,
-then you need to check your /etc/hosts.allow and
-/etc/hosts.deny files on the server and make sure
-your client actually is allowed access. Again, if the
-entries appear correct, check /etc/hosts (or your
-DNS server) and make sure that the machine is listed
-correctly, and make sure you can ping the server from
-the client. Also check the error logs on the system
-for helpful messages: Authentication errors from bad
-/etc/hosts.allow entries will usually appear in
-/var/log/messages, but may appear somewhere else depending
-on how your system logs are set up. The man pages
-for syslog can help you figure out how your logs are
-set up. Finally, some older operating systems may
-behave badly when routes between the two machines
-are asymmetric. Try typing __tracepath [[server]__ from
-the client and see if the word "asymmetric" shows up
-anywhere in the output. If it does then this may
-be causing packet loss. However asymmetric routes are
-not usually a problem on recent linux distributions.
-
-
-
-
- If you get the error Remote system error - No route
-to host, but you can ping the server correctly,
-then you are the victim of an overzealous
-firewall. Check any firewalls that may be set up,
-either on the server or on any routers in between
-the client and the server. Look at the man pages
-for __ipchains__, __netfilter__,
-and __ipfwadm__, as well as the
-IPChains-HOWTO
-and the Firewall-HOWTO for help.
-
-
-
-##
-#
-
-
-----
-!!7.4. I do not have permission to access files on the mounted volume.
-
- This could be one of two problems.
-
-
-
-
- If it is a write permission problem, check the export
-options on the server by looking at /proc/fs/nfs/exports
-and make sure the filesystem is not exported read-only.
-If it is you will need to re-export it read/write
-(don't forget to run __exportfs -ra__ after editing
-/etc/exports). Also, check
-/proc/mounts and make sure the volume
-is mounted read/write (although if it is mounted read-only
-you ought to get a more specific error message). If not then
-you need to re-mount with the rw option.
-
-
-
-
- The second problem has to do with username mappings, and is
-different depending on whether you are trying to do this
-as root or as a non-root user.
-
-
-
-
- If you are not root, then usernames may not be in sync on
-the client and the server. Type __id [
[user
]__
-on both the client and the server and make sure they give the
-same ''UID'' number. If they don't then
-you are having problems with NIS, NIS+, rsync, or whatever
-system you use to sync usernames. Check group names to make
-sure that they match as well. Also, make sure you are not
-exporting with the __all_squash__ option.
-If the user names match then the user has a more general
-permissions problem unrelated to NFS.
-
-
-
-
- If you are root, then you are probably not exporting with
-the __no_root_squash__ option; check /proc/fs/nfs/exports
-or /var/lib/nfs/xtab on the server and make sure the option
-is listed. In general, being able to write to the NFS
-server as root is a bad idea unless you have an urgent need --
-which is why Linux NFS prevents it by default. See
-Section 6 for details.
-
-
-
-
- If you have root squashing, you want to keep it, and you're only
-trying to get root to have the same permissions on the file that
-the user ''nobody'' should have, then remember that it is the server
-that determines which uid root gets mapped to. By default, the
-server uses the ''UID'' and ''GID'' of
-''nobody'' in the /etc/passwd file,
-but this can also be overridden with the __anonuid__ and
-__anongid__ options in the /etc/exports
-file. Make sure that the client and the server agree about which
-''UID'' ''nobody'' gets mapped to.
-
-
-----
-!!7.5. When I transfer really big files, NFS takes over
-all the CPU cycles on the server and it screeches to a halt.
-
- This is a problem with the fsync() function in 2.2 kernels that
-causes all sync-to-disk requests to be cumulative, resulting
-in a write time that is quadratic in the file size. If you
-can, upgrading to a 2.4 kernel should solve the problem.
-Also, exporting with the __no_wdelay__ option
-forces the program to use o_sync() instead, which may prove faster.
-
-
-----
-!!7.6. Strange error or log messages
-
-
-
-
-
-
-#
-
- Messages of the following format:
-
-
-
-
-
- Jan 7 09:15:29 server kernel: fh_verify: mail/guest permission failure, acc=4, error=13
-Jan 7 09:23:51 server kernel: fh_verify: ekonomi/test permission failure, acc=4, error=13
-
-
-
-
-
- These happen when a NFS setattr operation is attempted on a
-file you don't have write access to. The messages are
-harmless.
-
-
-
-#
-#
-
- The following messages frequently appear in the logs:
-
-
-
-
-
- kernel: nfs: server server.domain.name not responding, still trying
-kernel: nfs: task 10754 can't get a request slot
-kernel: nfs: server server.domain.name OK
-
-
-
-
-
- The "can't get a request slot" message means that the client-
-side RPC code has detected a lot of timeouts (perhaps due to
-network congestion, perhaps due to an overloaded server), and
-is throttling back the number of concurrent outstanding
-requests in an attempt to lighten the load. The cause of
-these messages is basically sluggish performance. See
-Section 5 for details.
-
-
-
-#
-#
-
- After mounting, the following message appears on the client:
-
-
-
-
-
-nfs warning: mount version older than kernel
-
-
-
-
-
- It means what it says: You should upgrade your mount package and/or
-am-utils. (If for some reason upgrading is a problem, you may be able
-to get away with just recompiling them so that the newer kernel features
-are recognized at compile time).
-
-
-
-#
-#
-
- Errors in startup/shutdown log for lockd
-
-
-
-
- You may see a message of the following kind in your boot log:
-
-nfslock: rpc.lockd startup failed
-
-
-
-
-
- They are harmless. Older versions of rpc.lockd needed to be
-started up manually, but newer versions are started automatically
-by knfsd. Many of the default startup scripts still try to start
-up lockd by hand, in case it is necessary. You can alter your
-startup scripts if you want the messages to go away.
-
-
-
-#
-#
-
- The following message appears in the logs:
-
-
-
-
-
-kmem_create: forcing size word alignment - nfs_fh
-
-
-
-
-
- This results from the file handle being 16 bits instead of a
-mulitple of 32 bits, which makes the kernel grimace. It is
-harmless.
-
-
-
-#
-
-
-----
-!!7.7. Real permissions don't match what's in /etc/exports.
-
- '' /etc/exports is VERY sensitive to whitespace - so the
-following statements are not the same:
-''
-
-/export/dir hostname(rw,no_root_squash)
-/export/dir hostname (rw,no_root_squash)
-
-The first will grant hostname rw access to /export/dir
-without squashing root privileges. The second will grant
-hostname rw privs w/root squash and it will grant EVERYONE
-else read-write access, without squashing root privileges.
-Nice huh?
-
-
-----
-!!7.8. Flaky and unreliable behavior
-
- Simple commands such as __ls__ work, but anything that transfers
-a large amount of information causes the mount point to lock.
-
-
-
-
- This could be one of two problems:
-
-
-
-
-
-
-
-#
-
-
-It will happen if you have ipchains on at the server and/or the
-client and you are not allowing fragmented packets through the
-chains. Allow fragments from the remote host and you'll be able
-to function again. See Section 6.4 for details on how to do this.
-
-
-
-#
-#
-
- You may be using a larger rsize and wsize in your mount options
-than the server supports. Try reducing rsize and wsize to 1024 and
-seeing if the problem goes away. If it does, then increase them
-slowly to a more reasonable value.
-
-
-
-#----
-!!7.9. nfsd won't start
-
- Check the file /etc/exports and make sure root has read permission.
-Check the binaries and make sure they are executable. Make sure
-your kernel was compiled with NFS server support. You may need
-to reinstall your binaries if none of these ideas helps.
-
-
-----
-!!!8. Using Linux NFS with Other OSes
-
- Every operating system, Linux included, has quirks and deviations
-in the behavior of its NFS implementation -- sometimes because
-the protocols are vague, sometimes because they leave gaping
-security holes. Linux will work properly with all major vendors'
-NFS implementations, as far as we know. However, there may be
-extra steps involved to make sure the two OSes are communicating
-clearly with one another. This section details those steps.
-
-
-
-
- In general, it is highly ill-advised to attempt to use a Linux
-machine with a kernel before 2.2.18 as an NFS server for non-Linux
-clients. Implementations with older kernels may work fine as
-clients; however if you are using one of these kernels and get
-stuck, the first piece of advice we would give is to upgrade
-your kernel and see if the problems go away. The user-space NFS
-implementations also do not work well with non-Linux clients.
-
-
-
-
- Following is a list of known issues for using Linux together with
-major operating systems.
-
-
-----
-!!8.1. AIX
-!8.1.1. Linux Clients and AIX Servers
-
- The format for the /etc/exports file for our example in Section 3 is:
-
- /usr slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com
-/home slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com
-
-
-
-----
-!8.1.2. AIX clients and Linux Servers
-
- AIX uses the file /etc/filesystems instead of /etc/fstab.
-A sample entry, based on the example in Section 4, looks like this:
-
-/mnt/home:
-dev = "/home"
-vfs = nfs
-nodename = master.foo.com
-mount = true
-options = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp
-account = false
-
-
-
-
-
-
-
-
-
-
-#
-
- Version 4.3.2 of AIX requires that file systems be exported with
-the insecure option, which causes NFS to listen to requests from
-insecure ports (i.e., ports above 1024, to which non-root users can
-bind). Older versions of AIX do not seem to require this.
-
-
-
-#
-#
-
- AIX clients will default to mounting version 3 NFS over TCP.
-If your Linux server does not support this, then you may need
-to specify vers=2 and/or proto=udp in your mount options.
-
-
-
-#
-#
-
- Using netmasks in /etc/exports seems to sometimes cause clients
-to lose mounts when another client is reset. This can be fixed
-by listing out hosts explicitly.
-
-
-
-#
-#
-
- Apparently automount in AIX 4.3.2 is rather broken.
-
-
-
-#
-
-
-----
-!!8.2. BSD
-!8.2.1. BSD servers and Linux clients
-
- BSD kernels tend to work better with larger block sizes.
-
-
-----
-!8.2.2. Linux servers and BSD clients
-
- Some versions of BSD may make requests to the server from insecure ports,
-in which case you will need to export your volumes with the insecure
-option. See the man page for ''exports(5)'' for more details.
-
-
-----
-!!8.3. Compaq Tru64 Unix
-!8.3.1. Tru64 Unix Servers and Linux Clients
-
- In general, Tru64 Unix servers work quite smoothly with Linux clients.
-The format for the /etc/exports file for our example in Section 3 is:
-
-
-/usr slave1.foo.com:slave2.foo.com \
--access=slave1.foo.com:slave2.foo.com \
-/home slave1.foo.com:slave2.foo.com \
--rw=slave1.foo.com:slave2.foo.com \
--root=slave1.foo.com:slave2.foo.com
-
-
-
-
-
- Tru64 checks the /etc/exports file every time there is a mount request
-so you do not need to run the __exportfs__ command; in fact on many
-versions of Tru64 Unix the command does not exist.
-
-
-----
-!8.3.2. Linux Servers and Tru64 Unix Clients
-
- There are two issues to watch out for
here. First, Tru64 Unix mounts
-using Version 3 NFS by default. You will see mount errors if your
-Linux server does not support Version 3 NFS. Second, in Tru64 Unix
-4.x, NFS locking requests are made by daemon. You will therefore
-need to specify the __insecure_locks__ option on all volumes you export
-to a Tru64 Unix 4.x client; see the __exports__ man pages for details.
-
-
-----
-!!8.4. HP-UX
-!8.4.1. HP-UX Servers and Linux Clients
-
- A sample /etc/exports entry on HP-UX looks like this:
-
-/usr -ro,access=slave1.foo.com:slave2.foo.com
-/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
-
-(The __root__ option is listed in the last entry for informational
-purposes only; its use is not recommended unless necessary.)
-
-
-----
-!8.4.2. Linux Servers and HP-UX Clients
-
- HP-UX diskless clients will require at least a kernel version 2.2.19
-(or patched 2.2.18) for device files to export correctly.
-
-
-----
-!!8.5. IRIX
-!8.5.1. IRIX Servers and Linux Clients
-
- A sample /etc/exports entry on IRIX looks like this:
-
-/usr -ro,access=slave1.foo.com:slave2.foo.com
-/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
-
-(The __root__ option is listed in the last entry for informational
-purposes only; its use is not recommended unless necessary.)
-
-
-
-
- There are reportedly problems when using the nohide option on
-exports to linux 2.2-based systems. This problem is fixed in the
-2.4 kernel. As a workaround, you can export and mount lower-down
-file systems separately.
-
-
-----
-!8.5.2. IRIX clients and Linux servers
-
- There are no known interoperability issues.
-
-
-----
-!!8.6. Solaris
-!8.6.1. Solaris Servers
-
- Solaris has a slightly different format on the server end from
-other operating systems. Instead of /etc/exports, the configuration
-file is /etc/dfs/dfstab. Entries are of the form of a "share"
-command, where the syntax for the example in Section 3 would
-look like
-
-share -o rw=slave1,slave2 -d "Master Usr" /usr
-
-and instead of running __exportfs__ after editing, you run __shareall__.
-
-
-
-
- Solaris servers are especially sensitive to packet size. If you
-are using a Linux client with a Solaris server, be sure to set
-__rsize__ and __wsize__ to 32768 at mount time.
-
-
-
-
- Finally, there is an issue with root squashing on Solaris: root gets
-mapped to the user ''noone'', which is not the same as the user ''nobody''.
-If you are having trouble with file permissions as root on the client
-machine, be sure to check that the mapping works as you expect.
-
-
-----
-!8.6.2. Solaris Clients
-
- Solaris clients will regularly produce the following message:
-
-
-
-svc: unknown program 100227 (me 100003)
-
-
- This happens because Solaris clients, when they mount, try to obtain
-ACL information - which linux obviously does not have. The messages
-can safely be ignored.
-
-
-
-
- There are two known issues with diskless Solaris clients: First, a kernel
-version of at least 2.2.19 is needed to get /dev/null to export
-correctly. Second, the packet size may need to be set extremely
-small (i.e., 1024) on diskless sparc clients because the clients
-do not know how to assemble packets in reverse order. This can be
-done from /etc/bootparams on the clients.
-
-
-----
-!!8.7. SunOS
-
- SunOS only has NFS Version 2 over UDP.
-
-
-----
-!8.7.1. SunOS Servers
-
- On the server end, SunOS uses the most traditional format for its
-/etc/exports file. The example in Section 3 would look like:
-
-/usr -access=slave1.foo.com,slave2.foo.com
-/home -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com
-
-
-
-----
-!8.7.2. SunOS Clients
-
- Be advised that SunOS makes all NFS locking requests as daemon, and
-therefore you will need to add the __insecure_locks__ option to any
-volumes you export to a SunOS machine. See the __exports__ man page
-for details
.
+Describe
[HowToNFSHOWTO
] here.
