1 This is version 1.1.0 of nfs-utils, the Linux NFS utility package.
6 Home page: http://sourceforge.net/projects/nfs/
8 To use the 'gss' support you must have kerberos-5 development
10 Otherwise use "--disable-gss"
12 To use nfsv4 support you need libevent and libnfsidmap development
13 libraries. They are available from
14 http://www.monkey.org/~provos/libevent/
15 http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/
16 Otherwise use --disable-nfsv4
18 To use the nfsdcld tracking daemon, nfsv4 support must be enabled,
19 and the libsqlite3 development libraries must be installed.
23 Unpack the sources and run these commands:
28 To install binaries and documenation, run this command:
35 Getting nfs-utils for the first time:
37 git clone git://linux-nfs.org/nfs-utils
39 Updating to the latest head after you've already got it.
43 Building requires that autotools be installed. To invoke them
48 Finally, build as usual as above.
50 3. DAEMON STARTUP ORDER
52 This nfs-utils packages does not provide any scripts for starting
53 various daemons as most distributions replace them with their own, so
54 any scripts we package would not get much testing.
55 Instead, we explain the dependencies involved in startup so that
56 scripts can be written to work correctly.
60 Name service (host name lookup) should be working before any
61 NFS services are started.
63 "portmap" must be running before any NFS services (server or
66 Normally network interfaces should be configured first as well,
67 though this isn't critical for the NFS server (providing name
68 service is handled locally).
73 A/ mount -t nfsd /proc/fs/nfsd
74 This filesystem needs to be mount before most daemons,
75 particularly exportfs, mountd, svcgssd, idmapd.
76 It could be mounted once, or the script that starts each daemon
77 could test if it is mounted and mount it if not.
80 These supply services to nfsd and so should be started before
81 rpc.nfsd. Where they come between mounting the nfsd filesystem
82 and starting the nfsd server is not important.
83 idmapd is only needed for NFSv4 support.
84 svcgssd is only needed if exportfs NFS filesystem with crypto-
87 C/ exportfs -av ; rpc.mountd
88 It is important that exportfs be run before mountd so that
89 mountd is working from current information (in
91 It is also important that both of these are run before
93 If not, any NFS requests that arrive before mountd is started
94 will get replied to with a 'Stale NFS File handle' error.
96 D/ rpc.statd --no-notify
97 It is best if statd is started before nfsd though this isn't
98 critical. Certainly it should be at most a few seconds after
100 When nfsd starts it will start lockd. If lockd then receives a
101 lock request it will communicate with statd. If statd is not
102 running lockd will retry, but it won't wait forever for a
104 Note that if statd is started before nfsd, the --no-notify
105 option must be used. If notify requests are sent out before
106 nfsd start, clients may try to reclaim locks and, on finding
107 that lockd isn't running, they will give up and never reclaim
109 rpc.statd is only needed for NFSv2 and NFSv3 support.
112 This daemon is only needed on kernels that support the nfsdcld
113 upcall, and only if the legacy client ID tracking isn't used. It
114 is also not needed if the server does not support NFSv4.
116 To determine whether you need this or not, do the following:
118 # cat /proc/fs/nfsd/versions
120 That should yield a list of NFS versions that this kernel supports,
121 if "4" or later is not in that list, or they are prefixed with a "-"
122 then you don't need to run this daemon. Next:
124 # cat /proc/fs/nfsd/nfsv4recoverydir
126 If that file is not present, or the directory that the above command
127 outputs is not present, then this daemon is required in order to
128 support lock recovery by the clients when the server reboots.
131 Starting nfsd will automatically start lockd. The nfs server
132 will now be fully active and respond to any requests from
136 This will notify any client which might have locks from before
137 a reboot to try to reclaim their locks. This should start
138 immediately after rpc.nfsd is started so that clients have a
139 chance to reclaim locks within the 90 second grace period.
140 sm-notify is only needed for NFSv2 and NFSv3 support.
146 This should be run shortly after boot and before any NFS
147 filesystems are mounted with remote-locking support -
148 filesystems can be mounted with "-o nolock" before sm-notify.
149 This is appropriate for '/', '/usr', and '/var'.
152 idmapd should be started before mounting any NFSv4 filesystems.
153 gssd should be started before mounting any NFS filesystems
154 securely (with Kerberos).
156 C/ statd should be run before any NFSv2 or NFSv3 filesystem is
157 mounted with remote locking (i.e. without -o nolock).
158 'mount' will try to use "/usr/sbin/start-statd" to start statd
159 if it is not already running, so there is no need to explicitly
160 start statd in boot-time scripts.
162 3.3. SERVER/CLIENT INTERACTIONS
165 Both the server and the client need sm-notify to be run.
166 It should be run after the NFS server is started, but before
167 and NFS filesystems are mounted with remote locking.
170 Both the server and the client need rpc.statd to be running.
171 Each should try to start when they need it.
175 Both the server and client need idmapd to be running. If idmapd
176 is started (for the client) before starting nfsd the 'nfsd'
177 filesystem is mounted, then idmapd should be sent a HUP signal
178 afterwards to signal that the server channels should be opened.
185 -- the nfs-utils developers
186 <linux-nfs@vger.kernel.org>