We've discussed sharing filesystems via SMB a few times. SMB lets you access files shared by a Windows system after jumping through only half a dozen loops. Sharing files with another Unix system is much, much simpler. FreeBSD supports the Unix standard Network File System out of the box. NFS intimidates many junior system administrators, but it's really quite simple once you know what's going on.
Each NFS connection works on a client-server model. One computer is the server and offers filesystems to other systems. This is called "NFS exporting," and the filesystems offered are called "exports." The clients can mount server exports in a manner almost identical to that used to mount local filesystems.
One interesting thing about NFS is its statelessness. You can reboot a server and the client won't crash. It won't be able to access files on the server's export while the server is down, but once it returns, you'll pick up right where things left off. Other network file sharing systems are not so resilient.
In this discussion, we're going to link multiple FreeBSD to 4-STABLE systems. Each NFS implementation is slightly different. You will find minor NFS variations between Solaris, Linux, BSD, and other Unixes. NFS should work between them all, but it might require the occasional tweak. If you have problems interoperating with some other Unix, check the freebsd-net mailing list archive; the issue has almost certainly been discussed there.
Let's configure some systems for NFS. Both server and clients require NFS support in the kernel, but the various NFS commands dynamically load the appropriate module into the kernel. FreeBSD's generic kernel supports NFS, but if you customize your kernel and don't like loading file system support as a module, be sure your kernel configuration includes:
First of all, we have the server side. You can enable basic NFS exports with the following rc.conf options:
Portmap provides, as you might guess, a mapping service for network
ports. Different exports and clients require unique network ports.
Clients ask portmap which port they should connect to for their actual
nfs_server_enable option starts nfsd and mountd. mountd
just listens for incoming NFS requests on assorted high-numbered
network ports, and makes these port numbers available to portmap.
When clients talk to portmap and mountd, nfsd actually handles their
Once you reboot, your server should show something like the following
sockstat(1) output. This shows that server-side NFS is
running more or less properly. If you don't see something resembling
/var/log/messages for log messages indicating your
# sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root rpc.stat 77 3 udp4 *:1011 *:* root rpc.stat 77 4 tcp4 *:1022 *:* root nfsd 70 3 tcp4 *:2049 *:* root mountd 68 3 udp4 *:1023 *:* root mountd 68 5 tcp4 *:1023 *:* daemon portmap 66 3 udp4 *:111 *:* daemon portmap 66 4 tcp4 *:111 *:*
Your client won't show any special
sockstat output before network
shares are mounted, but a
ps -ax will display several nfsiod
Now that your systems are prepared to handle NFS, we need to tell the
server which directories it can export. We could just export the
entire server, but that's not generally a good thing. Clients should
have little or no need to remote-mount the server's root filesystem,
for example. Define allowed exports in the
/etc/exports file. This
file has a separate line for each hard-drive partition on the server.
Each line has up to three components:
- the directories to be exported
- the options on that export
- the clients that can connect
Each combination of clients and server disk partition can only have
one line in the exports file. This means that if
/usr/home are on the same partition, they must be exported in the same
line to any one client. You don't have to export the entire partition,
mind you; you can just as easily share out a single directory within a
partition. This directory must be a true path, and it must not contain either
symlinks or double or single dots (i.e., ".."). If I wanted to export
my home directory to every host on the Internet, I could use an
/etc/exports line that consisted entirely of this:
We have no options and no host restrictions. Now that we've edited the exports file, we have to tell mountd to re-read it.
killall -1 mountd
Any problems will appear in
/var/log/messages. For example, when I
was first testing this, I had a single entry in
/home/mwlucas. It was about this time that I learned that
/etc/exports cannot contain symlinks. FreeBSD puts user home
/usr/home and uses a symlink to create the
directory. The error log gave me a warning like this:
Jan 24 07:13:35 server mountd: bad exports list line /home/mwlucas
This told me where the problem was; identifying the problem was my job.
Now, over on the client side, I create the directory
I want to NFS-mount my home directory on the server onto this
directory. This looks almost exactly like a standard mount(8)
command. mount takes two arguments: the physical device you're using
and the mount point. In this case, our physical device is a remote
server and the exported filesystem:
# mount server:/usr/home/mwlucas serverhome #
Once this finishes, test your mount with
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 99183 67411 23838 74% /
/dev/ad0s1f 5186362 3873110 898344 81% /usr
/dev/ad0s1e 198399 21211 161317 12% /var
procfs 4 4 0 100% /proc
server:/usr/home/mwlucas 34723447 3886523 28059049 12% /usr/home/mwlucas/serverhome
One thing to note is that NFS uses the same usernames on each side of the connection. My files are owned by mwlucas on the server, so they are owned by mwlucas on the client. This can be a problem on a large network where users have root on their own machines. To create a central repository of authorized users, consider Kerberos or NIS. On a small network, or on a network with limited administrators, this usually isn't a problem.
Pages: 1, 2