linux NFS配置

Linux NFS configuration services
By Adam Haeder

This is specific to RedHat, but most other Linux distributions follow the same pattern.

An NFS server on linux requires 3 services to be running in order to share files:

/etc/rc.d/init.d/portmap
/etc/rc.d/init.d/nfslock
/etc/rc.d/init.d/nfs

You can start/stop/restart these services by issues the above lines with the corresponding arguments: start, stop or restart. You can also use the shortcut 'service' command, as in:

# service portmap start

You need to ensure that these 3 services start up when the system does.

First, verify the default runlevel of the computer. Check the line in /etc/inittab that starts with "id:". The next number will be the default runlevel (usually 3 for non-gui, 5 for gui). You can manage the startup scripts manually by creating symlinks in the corresponding /etc/rc.d/rcX.d directory (where X is the default runlevel) or you can use redhat's "chkconfig" command. Assuming the default runlevel is 3, these 3 commands will ensure that the services necessary for an nfs server start at boot time (these all must run as root):

# chkconfig --level 3 portmap on
# chkconfig --level 3 nfslock on
# chkconfig --level 3 nfs on

Now either reboot the box or issue these commands to start the nfs server:

# service nfs stop
# service nfslock stop
# service portmap stop
# service portmap start
# service nfslock start
# service nfs start

Order is important. Portmap must start first, followed by nfslock, followed by nfs.

The file that defines what directories are shared is /etc/exports. 'man exports' will give you the full overview of all options available for this file. Here is an example line:

/public *(rw,no_root_squash)

This says share the folder /public, allow any IP access, give read/write access, and allow the root user to connect as root.

The * wildcard can be a list or range of IP addresses. For example, if we wanted to restrict this access to the 192.168.1.0/24 Class C subnet, the line would look like this:

/public 192.168.1.0/255.255.255.0(rw,no_root_squash)

rw means read/write. no_root_squash is a setting that allows nfs clients to connect as root. Without this setting, the root user on clients that connect has the permissions of the user 'nfsnobody', uid 65534.

Anytime you make any changes to the /etc/exports file, run the command:

# exportfs -avr
on the server to update the nfs server.

On to the nfs client:

On the client, you need the 'portmap' and 'nfslock' services running.  Follow the instructions above to ensure that these 2 services start with the default runlevel. Once they are running, you can mount a directory on the nfs server. If the server ip is 192.168.1.1 and the share name is public, you can do this on a client:

# mkdir /mnt/public
# mount 192.168.1.1:/public /mnt/public

You should get a prompt back. A 'mount' command should show you that the nfs share is mounted, and you should be able to cd to this directory and view the contents.

A couple of things to keep in mind with NFS: permissions are handled by UID. It is very beneficial to ensure that a user on the client has the same UID on the server. Otherwise the permissions will just confuse you.  If you are just using root, and using the no_root_squash option on every mount, you don't have to worry about this.

Security: NFS should stand for No F**king Security. It's all IP based, so if anyone can spoof an IP, they can mount on of your shares. NEVER do NFS over an untrusted network (like the internet) and ALWAYS restrict your shares to at least your local subnet.

There are 2 kinds of nfs mounts : soft mounts and hard mounts. With a soft mount, if the server goes away (reboot/lost network/whatever) the client can gracefully close the connection, unmount the share and continue on. However, in order for the client to maintain this ability, it has to do more caching of the reads and writes, so performace is lower and it's possible to lose data if the server goes away unexpectedly.

A hard mount means that the client never gives up trying to hit the server. Ever. Eventually the load on the client will be so high due to backed up i/o requests, you'll have to reboot it. Not all that good, but hard mounts don't have the caching overhead soft mounts do, so you have less chance of losing data.  I always use hard mounts, but then specify the 'intr' option on the mount, so I can unmount it manually if the server goes away (see example below).

Troubleshooting:
As with most things in linux, watch the log files. If you get an error on the client when trying to mount a share, look at /var/log/messages on the server. If you get an error like "RPC: program not registered" that means that the portmap service isn't running on one of the machines. Verify all the processes are running and try again.

Examples:
Here are some examples from one of my production linux nfs servers. On the server, a line from /etc/exports:

/aim/exports/clink192.168.23.0/255.255.255.0(rw,no_root_squash,async,wdelay)

Please see the manpage on exports for explanations of some of these options. Here is the corresponding /etc/fstab entry on a client that mounts this share (all on one line):

192.168.23.10:/aim/exports/clink /aim/imports/clink nfs
rsize=8192,wsize=8192,timeo=20,retrans=6,async,rw,noatime,intr 0 0

You might want to experiment with rsize and wsize parameters to get that last bit of performance. With this line in /etc/fstab, the mount is remounted at boot. I can also issue the command 'mount -t nfs -a' to mount all nfs entries in /etc/fstab with the corresponding options.