Sharing NFS File Systems

Sharing NFS File Systems
To share an NFS file system from your Linux system, you need to export it from the server system. Exporting is done in Linux by adding entries into the /etc/exportsfile. Each entry identifies a directory in your local file system that you want to share with other computers. The entry also identifies the other computers that can share the resource (or opens it to all computers) and includes other options that reflect permissions associated with the directory.
Remember that when you share a directory, you are sharing all files and subdirectories below that directory as well (by default). So, you need to be sure that you want to share everything in that directory structure.
Configuring the /etc/exports File
To make a directory from your Linux system available to other systems, you need to export that directory. Exporting is done on a permanent basis by adding information about an exported directory to the /etc/exports file. The format of the /etc/exportsfile is
Directory Host(Options) # Comments
where Directoryis the name of the directory that you want to share, and Hostindicates the host computer to which the sharing of this directory is restricted. Optionscan include a variety of options to define the security measures attached to the shared directory for the host. (You can repeat Host/Optionpairs.) Comments are any optional comments you want to add (following the #sign).
As root user, you can use any text editor to configure /etc/exportsto modify shared directory entries or add new ones. Here’s an example of an /etc/exports file:

/cal *.linuxtoys.net(rw) # Company events
/pub (ro,insecure,all_squash) # Public dir
/home maple(rw,squash uids=0-99) spruce(rw,squash uids=0-99)
The /cal entry represents a directory that contains information about events related to the company. It is made accessible to everyone with accounts to any computers in the company’s domain (*.linuxtoys.net). Users can write files to the directory as well as read them (indicated by the rwoption). The comment (#Company events) simply serves to remind you of what the directory contains.
The /pubentry represents a public directory. It allows any computer and user to read files from the directory (indicated by the ro option) but not to write files. The insecureoption enables any computer, even one that doesn’t use a secure NFS port, to access the directory. The all_squash option causes all users (UIDs) and groups (GIDs) to be mapped to the nfsnobody user, giving them minimal permission to files and directories.
The /homeentry enables a set of users to have the same /home directory on different computers. Say, for example, that you are sharing /home from a computer named oak. The computers named maple and spruce could each mount that directory on their own /homedirectories. If you gave all users the same username/UIDs on all machines, you could have the same /home/userdirectory available for each user, regardless of which computer they are logged into. The uids=0–99is used to exclude any administrative login from another computer from changing any files in the shared directory.
These are just examples; you can share any directories that you choose, including the entire file system (/). Of course, there are security implications of sharing the whole file system or sensitive parts of it (such as /etc). Security options that you can add to your /etc/exports file are described throughout the sections that follow.
Hostnames in /etc/exports
You can indicate in the/etc/exports file which host computers can have access to your shared directory in the following ways:



Individual host
You can enter one or more TCP/IP hostnames or IP Addresses. If the host is in your local domain, you can simply indicate the hostname. Otherwise, you can use the full host.domain format. These are valid ways of indicating individual host computers:
maple
maple.handsonhistory.com
10.0.0.11
IP network
To allow access to all hosts from a particular network address, indicate a network
number and its netmask, separated by a slash (/). These are valid ways of indicating network numbers:
10.0.0.0/255.0.0.0
172.16.0.0/255.255.0.0
192.168.18.0/255.255.255.0

TCP/IP domain
Yu can include all or some host computers from a particular domain level. Here are some valid uses of the asterisk and question mark wild cards:

*.handsonhistory.com
*craft.handsonhistory.com
???.handsonhistory.com
The first example matches all hosts in the handsonhistory.com domain. The second example matches
woodcraft, basketcraft, or any other hostnames ending in craft in the handsonhistory.com domain. The final example matches any three-letter hostnames in the domain.
Note Using an asterisk doesn’t match subdomains. For example, *.handsonhistory.com would not cause the
hostname mallard.duck.handsonhistory.com to be included in the access list.

NIS groups
You can allow access to hosts contained in an NIS group. To indicate a NIS group, precede the group name with an at (@) sign (for example, @group).
Link and access options in /etc/exports
You don’t have to just give away your files and directories when you export a directory with NFS. In the options part of each entry in /etc/exports, you can add options that allow or limit access based on user ID, subdirectory, and read/write permission. These options, which are passed to NFS, are as follows:
ro
Only allow the client to mount this exported file system read-only. The default is to mount the file system read/write.
rw
Explicitly ask that a shared directory be shared with read/write permissions. (If the client chooses, it can still mount the directory read-only.)
noaccess
All files and directories below the given directory are not accessible. This is how you would exclude selected subdirectories of a shared directory from being shared. The directory will still appear to the client that mounts the file system that includes this directory, but the client will not be able to view its contents.

link_relative
If absolute symbolic links are included in the shared file system (that is, ones that identify a full path), the full path is converted to a relative path. To do this, each part of the path is converted to two dots and a slash (../) to reach the root of the file system.
Link_absolute
Don’t change any of the symbolic links (default).

User mapping options in /etc/exports
Besides options that define how permissions are handled generally, you can also use options to set the permissions that specific users have to NFS shared file systems.
One method that simplifies this process is to have each user with multiple user accounts have the same user
name and UID on each machine. This makes it easier to map users so that they have the same permission on a
mounted file system as they do on files stored on their local hard disk. If that method is not convenient, user
IDs can be mapped in many other ways. Here are some methods of setting user permissions and the
/etc/exports option that you use for each method:


root user
Normally, the client’s root user is mapped into the anonymous user ID. This prevents the root user from a client computer from being able to change all files and directories in the shared file system. If you want the client’s root user to have root permission on the server, use the no_root_squash option.
There may be other administrative users, in addition to root, that you want to squash. I recommend squashing UIDs 0–99 as follows: squash_uids=0–99.
Anonymous user/group
By using anonymous user ID and group ID, you essentially create a user/group whose permissions will not allow access to files that belong to any users on the server (unless those users open permission to everyone). However, files created by the anonymous user/group will be available to anyone assigned as the anonymous user/group. To set all remote users to the anonymous user/group, use the all_squash option.
The anonymous user assigned by NFS is typically the "nobody" user name with a UID and GID -2 (because -2 cannot be assigned to a file, UIDs and GIDs of 65534 are assigned when the "nobody" user owns a file). This prevents the ID from running into a valid user or group ID. Using anonuid or anongid, you can change the anonymous user or group, respectively. For example, anonuid=175 sets all anonymous users to UID 175 and anongid=300 sets the GID to 300.
User mapping
If the same users have login accounts for a set of computers (and they have the same IDs), NFS, by default, will map those IDs. This means that if the user named mike (UID 110) on maple has an account on pine (mike, UID 110), from either computer he could use his own remotely mounted files from the other computer.
If a client user that is not set up on the server creates a file on the mounted NFS directory, the file is assigned to the remote client’s UID and GID. (An ls -l on the server would show the UID of the owner.) You can identify a file that contains user mappings using the map_static option.
The exports man page describes the map_static option, which should let you create a file that contains new ID mappings. These mappings should let you remap client IDs into different IDs on the server.
Exporting the Shared File Systems
After you have added entries to your /etc/exportsfile, run the exportfscommand to have those directories exported (made available to other computers on the network). Reboot your computer or restart the NFS service, and the exportfscommand runs automatically to export your directories.
If you want to export them immediately, run exportfsfrom the command line (as root). It’s a good idea to run the exportfs command after you change the exports file. If any errors are in the file, exportfs identifies them for you.
Here’s an example of the exportfscommand:

# /usr/sbin/exportfs -a -
exporting maple:/pub
exporting spruce:/pub
exporting maple:/home
exporting spruce:/home
exporting *:/mnt/win
The –a option indicates that all directories listed in /etc/exportsshould be exported.
The -v option says to print verbose output. In this example, the /puband /home directories from the local server are immediately available for mounting by those client computers that are named (maple and spruce). The /mnt/windirectory is available to all client computers.
Running the exportfscommand temporarily makes your exported NFS directories available. To have your NFS directories available on an ongoing basis (that is, every time your system reboots), you need to set your nfs startup scripts to run at boot time.