1. The Network File System
Chapter 17

2. Chapter 17 -The Network File System
Introduction
The Network File System, commonly known as NFS, allows you to share filesystems among computers.
NFS is almost transparent to users and is “stateless,”
meaning that no information is lost when the NFS server crashes.
Clients can simply wait until the server returns and then continue as if nothing happened.
Chapter 17 -The Network File System

3. Chapter 17 -The Network File System
Introduction
NFS was introduced by Sun Microsystems in 1985.
It was originally implemented as a surrogate filesystem for diskless clients.
The protocol proved to be well designed and very useful as a general file-sharing solution.
All UNIX vendors provide a version of NFS
many use code licensed from Sun
Chapter 17 -The Network File System

4. 1. General Information about NFS
Introduction:
NFS consists of a number of components including:
a mounting protocol
mount server,
daemons that coordinate basic file service
server diagnostic utilities
Chapter 17 -The Network File System

5. 1. General Information about NFS
NFS Protocol Versions
The NFS protocol has been remarkably stable over time.
The original public release of NFS was version2.
Version 3 came out in the early 1990s (a collection of changes to increase performance and provide better support for large files.
Chapter 17 -The Network File System

6. 1. General Information about NFS
Choice of transport
NFS runs on top of Sun’s RPC (Remote Procedure call) protocol, which defines a system-independent way for processes to communicate over a network.
Therefore it is possible to use UDP or TCP
NFS and UDP do not do congestion control. (the original setup)
Most systems now allow you to use TCP as the transport for NFS instead of UDP
Chapter 17 -The Network File System

7. 1. General Information about NFS
Choice of transport (cont)
Table 17.1 pg 490
Chapter 17 -The Network File System

8. 1. General Information about NFS
File locking
File locking (as provided by flock and/or lock system calls) has been a sore point on UNIX systems for a long time.
On local filesystems it has been known to work less than perfectly.
In the context of NFS the ground is shakier still.
Since the NFS servers are stateless they have no idea which machines (or processes) are using a given file,
But this is needed for locking…..so, what to do?
Chapter 17 -The Network File System

9. 1. General Information about NFS
File locking (cont.)
The traditional answer has been to implement file locking separately from NFS
Most systems provide two daemons, lockd and statd, that try to make a go of it.
Unfortunately, the task is difficult for a variety of subtle reasons and NFS file locking has generally tended to be flaky.
Chapter 17 -The Network File System

10. 1. General Information about NFS
Disk quotas
Access to remote disk quota information can be provided by a similar out-of-band server, rquotad.
An NFS server will enforce disk quotas, but servers cannot view their quota information unless rquotad is running on the remote server.
Chapter 17 -The Network File System

11. 1. General Information about NFS
Global UIDs and GIDs
UNIX identifies users and groups by number.
If machine X shares files with machine Y, then UID 644 had better refer to the same user on both systems or a serious security or privacy problem could result.
NFS servers need not allow remote users to log in.
Chapter 17 -The Network File System

12. 1. General Information about NFS
Root access and the nobody account
While users should be given identical privileges wherever they go, it’s traditional to prevent root from running rampant on NFS-mounted filesystems.
By default, NFS servers intercept incoming requests made on behalf of UID o and change them to look as if they are coming from some other user.
Remember, root on an NFS client can su to whatever UID it desires, so user files are never really protected.
Chapter 17 -The Network File System

13. 1. General Information about NFS
Cookies and stateless mounting
A client must explicitly mount an NFS filesystem before using it.
However, because NFS is stateless, the server does not keep track of which clients have mounted each filesytem.
Instead the server gives a “cookie” upon a successful mount and that cookie identifies the mounted directory to the NFS server
Cookies persist across NFS server reboots (unless they went to single-user mode and then back up)
Chapter 17 -The Network File System

14. 1. General Information about NFS
Security and NFS
NFS provides a convenient way to access files on a network, and thus it has great potential to cause security problems
In may ways NFS is a poster child for everything that is or ever has been wrong with UNIX security.
The NFS protocol was originally designed with essentially no concern for security.
Authentication modules were later allowed (but not required) in the RPC protocol.
Sun’s public key and Kerberos
Chapter 17 -The Network File System

15. 1. General Information about NFS
Security and NFS (cont.)
The greatest risk is presented by on-site machines that are legally allowed to mount a filesytem.
If anyone that you don’t fully trust (that means they are breathing still) has root access on a client host, don’t export any filesystems to that host.
If your site has a firewall, it is a good idea to block access to TCP and UDP ports 2049 (used by NFS) and 111 (used by SunRPC portmap daemon)
Chapter 17 -The Network File System

16. Chapter 17 -The Network File System
2. Server-side NFS
Introduction:
A server is usually said to “export” a directory when it makes the directory available for use by other machines.
Solaris uses the word “share”
The process used by clients to mount a filesystem (get the cookie) is completely separate from the process used to access files.
Separate protocols and separate daemons
mountd and nfsd sometimes called rpc.nfsd and rpc.mountd
Chapter 17 -The Network File System

17. Chapter 17 -The Network File System
2. Server-side NFS
Introduction: (cont)
On an NFS server, both mountd and nfsd should start when the system boots.
They share a single access control database
which filesystems should be exported and which clients may mount them.
Kept in xtab or sharetab
You use eportfs to update these files
Most systems have a human readable file that is used (at boot time) to create xtab - this file is usually /etc/exports
Chapter 17 -The Network File System

18. Chapter 17 -The Network File System
2. Server-side NFS
Introduction: (cont)
FreeBSD consults this file (/etc/exports) directly
after modifying this file you must send mountd a HUP signal to tell it to read the file’s contents again.
kill -HUP `cat /var/run/mountd.pid`
Table 17.2 pg 494
Chapter 17 -The Network File System

19. Chapter 17 -The Network File System
2. Server-side NFS
Introduction: (cont)
NFS deals with the logical layer of the filesystem.
Any directory can be exported
But sub mounted systems will not go with it.
Clients are allowed to mount subdirectories of an exported system if they wish.
If /users is exported to them, they can mount /users/joe and ignore the rest.
Chapter 17 -The Network File System

20. Chapter 17 -The Network File System
2. Server-side NFS
The exportfs command and the exports file (H-UX, Red Hat, FreeBSD)
The exports file conssts of a list of exported directories in the leftmost column, followed by lists of associated options and attributes
Example:
/chimchim/users -access=band:moon,root=band
/usr/share/man -access=xorasaurus:rastadon:moon,ro
Chapter 17 -The Network File System

21. Chapter 17 -The Network File System
2. Server-side NFS
The exportfs command and the exports file (H-UX, Red Hat, FreeBSD) (cont)
Filesystems that are listed in the exports file without a specific set of hsots are usually mountable by all machines
This is a sizeable security hole.
Some NFS implementation limit lines in the exports file to 1,024 characters.
That limit can come awfully fast, especially when you’re using fully qualified domain names
Chapter 17 -The Network File System

22. Chapter 17 -The Network File System
2. Server-side NFS
nfsd: serve files
Once a client’s mount request has been validated by mountd, it can request carious filesystem operations.
These requests are handled on the server side by nfsd, the NFS operations daemon.
Chapter 17 -The Network File System

23. Chapter 17 -The Network File System
2. Server-side NFS
nfsd: serve files
nfsd takes a numeric argument that specifies the number of copies of itself that it should fork.
Selecting the appropriate number is important and unfortunately something of a black art.
Too high or too low and NFS performance suffers.
There is no reason to run more than a few nfsd’s per spindle.
You can watch the load (goes up if too many) and UDP packets dropped (with netstat -s) for too few.
Chapter 17 -The Network File System

24. Chapter 17 -The Network File System
3. Client-side NFS
Introduction
mount understand the notation hostname:directory to mean the path directory interpreted by hostname
On most systems, the optional but highly recommended daemon biod (block I/O daemon, sometimes called nfsiod) provides performance enhancements.
Chapter 17 -The Network File System

25. Chapter 17 -The Network File System
3. Client-side NFS
biod and nfsiod: provide client-side caching
The provide read-ahead and write-behind filesystem block caching.
We suggest that you run it on NFS clients that provide it, but that is not strictly required.
The presence or absence does not affect administration.
This daemon can also have multiple copies running
On a garden variety machine 4 or 8 should be plenty.
Chapter 17 -The Network File System

26. Chapter 17 -The Network File System
3. Client-side NFS
Mounting remote filesystems
You can use the mount command to establish temporary network mounts.
You should list mounts that are part of a system’s permanent configuration in /etc/fstab so that they are automatically mounted at boot time.
Or you can use an automounter like automount or amd
NFS partitions can be unmounted with the umount command
Chapter 17 -The Network File System

27. Chapter 17 -The Network File System
3. Client-side NFS
Mounting remote filesystems (cont)
Table 17.9 g 502
Chapter 17 -The Network File System

28. Chapter 17 -The Network File System
3. Client-side NFS
Secure port restrictions
NFS clients are free to use any TCP or UDP port they like.
However, some servers may insist that the requests come from a privileged port (<1024)
In the world of PCs and desktop UNIX boxes, the use of a privileged port provides little actual security.
Chapter 17 -The Network File System

29. 4: NFSSTAT: Dump NFS Statistics
Most systems provide a command called nfsstat that can display various statistics kept by the NFS system.
nfsstat -s show stats for the server
nfsstat -c shows stats for the client
Running nfsstat occasionally and becoming familiar with its output will help you discover NFS problems before your users do.
Chapter 17 -The Network File System

30. 5. Dedicated NFS File Servers
Fast reliable file service is one of the most important elements of any production computing environment.
Dedicated FS file servers have been around for more than a decade.
They offer a host of potential advantages over the homebrew approach.
Of the current offerings, Network Appliance makes some very good ones.
Chapter 17 -The Network File System

31. Chapter 17 -The Network File System
6. Automatic Mounting
Mounting filesystems one at a time by listing them in /etc/fstab or /etc/vfstab introduces a number of problems in large networks.
Automounters are very important for large networks of machines.
Sun has produced automount and there is another package called amd that is open source and very good.
The next two sections of the text cover these programs.
Chapter 17 -The Network File System

32. Chapter 17 -The Network File System
9. Recommended Reading
Callaghan, Brent. NFS Illustrated. Addison-Wesley, 1999.
Pendy, Jan-Simon, and Nick Williams. “AMD: The 4.4BSD Automounter Reference Manual.” 4.4 BSD System Manager’s Manual, Usenix and O’Rielly
Stern, Hal. Manageing NFS and NIS. Sebastopol: O’Rielly & Associates, 1992.
Chapter 17 -The Network File System

33. Chapter 17 -The Network File System
9. Recommended Reading
Table pg 512
Chapter 17 -The Network File System

34. Chapter 17 -The Network File System