Novell Home

A Tour of NFS

Novell Cool Solutions: Feature
By Kirk Coombs

Digg This - Slashdot This

Posted: 15 Sep 2005
 

Applies To:

  • SUSE Linux
  • SUSE Linux Enterprise Server
  • Open Enterprise Server
  • Novell Linux Desktop

Overview of NFS

NFS, or Network File System was created by Sun as a nearly seamless way to share files among UNIX-based Operating Systems. It allows a directory on a server to be shared--specifying what hosts can connect, whether the share can be written to, and whether to use the real Linux users or an anonymous user. 

A unique aspect of NFS, which makes it appear seamless to the end-user, is that connecting to a NFS share does not require a password, and files on the server appear in every respect to be a users' own files. Security is enforced by limiting access to trusted hosts, and by using the standard Linux file system permissions. The UIDs and GIDs of users are mapped from the server to the client. Thus if a user on a client has the same UID and GID as a user on the server, they have access to files in the NFS share owned by that UID and GID. NFS is easy to grasp, which leads to quick and easy configuration. It is important to note, however, that NFS does not employ encrypted communication, making it possible for data to be caught in transmission by a third-party. In addition, improper management of users on a client can incorrectly give file access to the wrong user. It is critical that the administrators of all allowed hosts are trusted.

SUSE Linux includes two YaST modules which make administering NFS shares a simple matter, once the underlying basics are understood. When creating a share several pieces of information are needed.

  1. The path to the share.
  2. The hosts which are allowed to connect.
  3. Any options for the share.

The hosts permitted to connect to a share can be specified in several ways (taken from the exports(5) man page):

  • single host - This is the most common format. You may specify a host either by an abbreviated name recognized be the resolver, the fully qualified domain name, or an IP address.
  • netgroups - NIS netgroups may be given as @group. Only the host part of each netgroup members is consider in checking for membership. Empty host parts or those containing a single dash (-) are ignored.
  • wildcards - Machine names may contain the wildcard characters * and ?. This can be used to make the exports file more compact; for instance, *.cs.foo.edu matches all hosts in the domain cs.foo.edu. As these characters also match the dots in a domain name, the given pattern will also match all hosts within any subdomain of cs.foo.edu.
  • IP networks - You can also export directories to all hosts on an IP (sub-) network simultaneously. This is done by specifying an IP address and netmask pair as address/netmask where the netmask can be specified in dotted-decimal format, or as a contiguous mask length (for example, either `/255.255.252.0' or `/22' appended to the network base address result in identical subnetworks with 10 bits of host). Wildcard characters generally do not work on IP addresses, though they may work by accident when reverse DNS lookups fail.

There are many options for shares. Here are some of the most common:

  • root_squash - Maps the root user to the nobody user. This has the effect of not allowing a root user on a client to gain root file access permissions on the server.
  • no_root_squash - Does not map the root user to the nobody user. The root user on a client has the same rights as the root user on the server.
  • all_squash - Maps all the UIDs and GIDs to the nobody user. This is useful if the share is to have anonymous access, much like an anonymous FTP server.
  • anonuid, anongid - If root_squash and all_squash are used, the UIDs and GIDs are mapped to the specified UID and GID instead of the nobody user.
  • ro - Forces all files on the share to be read-only. This is the default behavior.
  • rw - Allows write access to the share.
  • sync - Ensures data is written to disk before another request is serviced.

NFS shares are stored in the /etc/exports file, and are specified one per line. Each share can contain several hosts/options declarations. The general syntax is:

/share_path    hosts_1(options) hosts_2(options) ... hosts_n(options)

For example:

/share_path    *(ro,all_squash) 137.65.208.12(rw,root_squash)

For more examples, see the exports(5) man page.

To mount a NFS share on a client, add the share to the /etc/fstab file. The syntax is:

host:/share_path    /local_mount_point    nfs    options  dump fsck

For example:

server.cs.foo.edu:/nfs_share    /share    nfs    defaults 0 0

The NFS server is controlled with the /sbin/rcnfsserver script, and the client is controlled with the /sbin/rcnfs script. The major options are:

  • start
  • stop
  • restart

For example, to start the server, execute:

# rcnfsserver start

A NFS Example

As an example, consider two computers, Arthur (IP: 137.65.208.137) and Caesar (IP: 137.65.209.139). Arthur is to be a server, containing a shared folder for several users. Caesar is a workstation which will mount the NFS share for user access. All users should have read/write access, but should not be able to violate the permissions set by the file owners.

The first step is to create the shared folder and users on Arthur, and the users on Caesar. Because all users will be using the same folder it is a good idea to set the sticky bit on the folder so the users cannot delete files they don't own:

Arthur:~ # mkdir /sharedfiles
Arthur:~ # chmod 1777 /sharedfiles

Create the users and groups on Arthur and Caesar as specified in Table 1 and Table 2. Notice the switching of the order of the users john and geeko. This is important later on. Create files in /sharedfiles for each user, with varying permissions:

Arthur:~ # ll /sharedfiles/
total 1
drwxrwxrwt   2 root  root    216 Sep 12 11:35 .
drwxr-xr-x  22 root  root    520 Sep 12 10:49 ..
-rw-------   1 geeko users     0 Sep 12 10:50 geeko_secret_file
-rw-r-----   1 jake  Authors   0 Sep 12 10:52 jake_shared_file
-rw-r-----   1 jane  Authors   0 Sep 12 10:52 jane_shared_file
-rw-r--r--   1 john  users     0 Sep 12 11:06 john_shared_file
-rw-------   1 root  root      0 Sep 12 11:35 root_secret_file

Table 1: Users on Arthur

Name UID users (GID 100) Authors (GID 1000)
john 1000 x -
geeko 1001 x -
jake 1015 x x
jane 1020 x x

Table 2: Users on Caesar
Name UID users (GID 100) Authors (GID 1000)
geeko 1000 x -
john 1001 x -
jake 1015 x x
jane 1020 x x

Now, use YaST to create a NFS share on Arthur. This is accomplished with the NFS Server module, found under Network Services. The first time it is run it prompts to start the NFS server on boot and installs an additional RPM. Create a NFS share as shown in Figure 1. Notice that access is limited to the trusted host 137.65.209.139, which is Caesar.

Figure 1
NFS Server Configuration

YaST saves the share (writes /etc/exports) and starts the NFS service (the equivalent of executing /sbin/rcnfsserver start). The share can now be seen in /etc/exports:

Arthur:~ # cat /etc/exports
/sharedfiles    137.65.209.139(rw,root_squash,sync)
Next, configure Caesar to mount the NFS share. Use the NFS Client module found under Network Services in YaST, as shown in Figure 2.

Figure 2
NFS Client Configuration

Notice that this module just writes the /etc/fstab file, and executes /sbin/rcnfs start.

Caesar:/ # cat /etc/fstab
--snip--
137.65.208.137:/sharedfiles     /share  nfs     defaults 0 0

Now, on Caesar, test the share.  As root, attempt to write a file, or delete one of root's files.

Caesar:/ # touch /share/root_shared_file
Caesar:/ # ll /share/
total 1
drwxrwxrwt   2 root   root    248 Sep 12  2005 .
drwxr-xr-x  22 root   root    512 Sep 12 10:20 ..
-rw-------   1 john   users     0 Sep 12  2005 geeko_secret_file
-rw-r-----   1 jake   Authors   0 Sep 12  2005 jake_shared_file
-rw-r-----   1 jane   Authors   0 Sep 12  2005 jane_shared_file
-rw-r--r--   1 geeko  users     0 Sep 12  2005 john_shared_file
-rw-------   1 root   root      0 Sep 12  2005 root_secret_file
-rw-r--r--   1 nobody nogroup   0 Sep 12  2005 root_shared_file
Caesar:/ # rm /share/root_secret_file
rm: remove write-protected regular empty file
`/share/root_secret_file'? y
rm: cannot remove `/share/root_secret_file': Operation not permitted

Notice that Arthur is not allowed root file access. When root creates a file, it is created as nobody.nogroup--this is because the share has the root_squash option.

Next, try to write to a file owned by geeko

Caesar:/ # su - geeko
geeko@Caesar:~> echo "This is Geeko's file!" > /share/geeko_secret_file
-bash: /share/geeko_secret_file: Permission denied
geeko@Caesar:~> echo "This is Geeko's file!" > /share/john_shared_file
geeko@Caesar:~> cat /share/john_shared_file
This is Geeko's file!

Notice that geeko cannot write to his file, but can write to john's file. This is because geeko and john have their UIDs switched on Caesar. This illustrates the importance to ensuring the the clients are trusted and configured properly to match the server.

Suppose that root file access is needed. Go back to Arthur and change the root_squash option to no_root_squash and restart the service.

Arthur:~ # cat /etc/exports
/sharedfiles    137.65.209.139(rw,no_root_squash,sync)
Arthur:~ # rcnfsserver restart
Shutting down kernel based NFS server                        done
Starting kernel based NFS server                             done

Return to Caesar and attempt to manipulate the root files.

Caesar:/ # touch /share/root_shared_file2
Caesar:/ # rm /share/root_secret_file
Caesar:/ # ll /share/
total 5
drwxrwxrwt   2 root   root    288 Sep 12  2005 .
drwxr-xr-x  22 root   root    512 Sep 12 10:20 ..
-rw-------   1 john   users     0 Sep 12  2005 geeko_secret_file
-rw-r-----   1 jake   Authors   0 Sep 12  2005 jake_shared_file
-rw-r-----   1 jane   Authors   0 Sep 12  2005 jane_shared_file
-rw-r--r--   1 geeko  users    22 Sep 12  2005 john_shared_file
-rw-r--r--   1 nobody nogroup   0 Sep 12  2005 root_shared_file
-rw-r--r--   1 root   root      0 Sep 12  2005 root_shared_file2

Now root permission is given, as expected.

Suppose that none of the users' rights should be honored. On Arthur change no_root_squash to all_squash and restart the service.

Arthur:~ # cat /etc/exports
/sharedfiles    137.65.209.139(rw,all_squash,sync)
Arthur:~ # rcnfsserver restart
Shutting down kernel based NFS server                        done
Starting kernel based NFS server                             done

Now, try to write files as a couple of users.

Caesar:/ # echo "Root's File" > /share/root
Caesar:/ # su - jane
jane@Caesar:~> echo "Jane's File" > /share/jane
Caesar:/ # ll /share
total 13
drwxrwxrwt   2 root   root    304 Sep 12  2005 .
drwxr-xr-x  22 root   root    512 Sep 12 10:20 ..
-rw-------   1 john   users     0 Sep 12 10:50 geeko_secret_file
-rw-r-----   1 jake   Authors   0 Sep 12 10:52 jake_shared_file
-rw-r--r--   1 nobody nogroup  12 Sep 12  2005 jane
-rw-r-----   1 jane   Authors   0 Sep 12 10:52 jane_shared_file
-rw-r--r--   1 geeko  users    22 Sep 12  2005 john_shared_file
-rw-r--r--   1 nobody nogroup  12 Sep 12  2005 root
-rw-r--r--   1 nobody nogroup   0 Sep 12  2005 root_shared_file
-rw-r--r--   1 root   root      0 Sep 12  2005 root_shared_file2

Notice that everybody is mapped to nobody.nogroup.

It is instructive to illustrate what happens when a user exists on the server but not the client. Create another user on Arthur and create a file as that user.

Arthur:~ # su - kirk
kirk@Arthur:~> touch /sharedfiles/kirk_file
kirk@Arthur:~> ll /sharedfiles/
total 12
--snip--
-rw-r--r--  1 kirk   users    0 2005-09-12 12:00 kirk_file

On Caesar, notice that the user comes through as a UID, not a user name. This is because users are mapped with their UIDs/GIDs and Caesar has no mapping for that user.

Caesar:/ # ll /share
total 13
drwxrwxrwt   2 root   root    336 Sep 12  2005 .
drwxr-xr-x  22 root   root    512 Sep 12 10:20 ..
--snip--
-rw-r--r--   1   1021 users     0 Sep 12  2005 kirk_file

Conclusion

NFS, when properly configured, can create a nearly seamless method to share files that require user permissions to remain intact. This tour showed the most common options and use-cases but was not in any way comprehensive. For example, NFS can be used in mixed environments as well--including various UNIX flavors, Windows, and Macintosh. For more in-depth information begin by reading the exports(5) and and nfs(5) man pages and the Linux NFS FAQ at http://nfs.sourceforge.net/.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell