File Sharing

In other chapters we have discussed many UNIX system commands that allow you to use resources on remote machines. These commands include those from the UUCP system (see the Companion web Site) and those in the TCP/IP Internet package. However, when you use any of these commands, you must supply the name of the remote system that contains the resource. In other words, you treat remote resources differently from those on your own system. You cannot use them exactly as you use resources on your local machine.

UNIX uses a distributed file system environment that lets you use remote resources on a network much as you use local resources. Distributed file systems help make all the machines on a network act as if they are all one large computer, even though the computers may be in different locations. Often users and processes on a computer use resources located somewhere on the network without caring, or even knowing, that these resources are physically located on a remote computer.

The Network File System (NFS), developed by Sun Microsystems, is a distributed file system used across all of the major UNIX variants. NFS was built to share files across heterogeneous networks, containing machines running operating systems other than the UNIX System. For this chapter it is assumed that you already have a network running NFS. Chapter 17 will discuss the administration of NFS including how to start running the package on your network, how to configure the packages, and how to maintain its operation.

Distributed File System Basics

Distributed file systems are based on a client/server model. As described previously, a computer on a network that can share some or all of its file systems with one or more other computers on the network is the server. A computer that accesses file systems residing on other computers is the client. A machine in a network can share resources with other computers at the same time it accesses file systems from other machines. This means that a computer can be both a client and a server at the same time.

A computer can offer any of its directory trees for sharing by remote machines in a network. A machine becomes a client of this server when it mounts this remote file system on one of its directories, which is called the mount point, just as it would mount a local file system (see Chapters 13 and 14).

For instance, in Figure 15–1 the client machine jersey has mounted the directory tree, under the directory tools, on the server machine colorado, on the mount point utilities, which is a directory created on jersey for this purpose. Once this mount has taken place, a user on jersey can access the files in this directory as if they were on the local machine. However, a user on jersey has no direct access to files on colorado not under the directory tools, such as the directory private shown in Figure 15–1.

Figure 15–1: Mounting a remote resource

For instance, a user on the client jersey runs the program scheduler, located on the server colorado in the directory /tools/factor, by typing

 $ /utilities/factor/scheduler

Similarly, to list all the files in the directory sort, a user on the client jersey types

 $ ls /utilities/sort

Benefits of Distributed File Systems

Distributed file systems help you use all the resources on a network in a relatively consistent, transparent, and effective way. With a distributed file system, you access and use remote resources with commands that are often identical to those needed to carry out the same operations on local resources. This means that you do not have to remember different sets of commands for local and for remote files. Also, when a distributed file system is employed, you do not have to know the actual physical location of a resource to be able to use it. You do not have to make your own copies of files to use them.

Because files can be transparently shared, you can add a new computer to a network when the computers on the network run out of storage capacity, making it unnecessary to replace computers with larger ones. Furthermore, you can keep important data files or programs on one or a few designated machines in a network when you use a distributed file system. This makes it unnecessary to keep copies of files on every machine, reducing the need for disk space and for maintaining the same versions of files on every machine.

NFS Features

The Network File System was designed to allow file sharing between computers running a variety of different operating systems. For instance, NFS can be used for file sharing between computers running different UNIX variants, as well as UNIX systems connected to non-UNIX systems (such as Windows machines).

NFS is built on top of the Remote Procedure Call (RPC) interface. RPC is implemented through a library of procedures together with a daemon running on a remote host. The daemon is the agent on the remote host that executes the procedure call made by the calling process. RPC has been designed so that it can run on a wide range of machines. When a client mounts an NFS resource shared by a server, the mounting process carries out a series of remote procedure calls to access the resource on the server. NFS data exchange between different machines is carried out using the external data representation (XDR). Currently, NFS v2 operates over the connectionless User Datagram Protocol (UDP) at the transport layer and Internet Protocol (IP) at the network layer. NFS v3 operates over TCP, and NFS v4 allows NFS over HTTP

A secondary goal in the design of NFS was easy recovery when network problems arise. An NFS server does not keep any information on the state of its local resources. That is, the server does not maintain data about which of its clients has files open at a given time. Because of this, NFS is said to be a stateless service. Servers keep no information on interactions between its clients and its resources.

Because NFS is stateless, an NFS server does not care when one of its clients crashes. The server just continues to operate as before the client crashed. When a server crashes, client processes that use server resources will wait until the server comes back up.

NIS/NIS+ Servers

Today’s typical network consists of a number of file and print servers, as well as clients of all sizes from personal computers to workstations. Users and administrators move from machine to machine to perform different tasks, but they still expect to share the same resources. Coordination of moving files from one machine to another while retaining ownership is an administrative headache, as are assignment and maintenance of user IDs on different machines, adding and tracking new hosts, and so on. UNIX provides a server environment that addresses file sharing in a heterogeneous network.

NIS (Network Information Services) is a network information service that supports distributed databases for maintaining certain administrative files for an entire network, including files containing password information, group information, and host addresses. NIS was developed by Sun Microsystems and for a long time was called Yellow Pages, or YP for short. Over the past few years, Sun has evolved the NIS architecture into a newer management system called NIS+. Although both NIS and NIS+ are used on the major UNIX variants and run pretty much the same way, NIS+ provides additional security features over NIS and is therefore becoming the preferred resource management service. We will discuss NIS+ more in Chapter 17. We will, however, discuss here a little about the way NIS and NIS+ are architected.

NIS/NIS+ itself runs in a client/server model. An NIS client is a client that runs processes that request data from the NIS servers. Applications using NIS/NIS+ do not need to know the location of the database containing information they need. Instead, NIS/NIS+ will locate the information on an NIS server and provide it in the form requested by the application.

There are two types of NIS/NIS+ servers, domain masters and slaves. Domain masters hold all of the database source files for the entire domain. Because NIS/NIS+ services are critical and need to be available even if the NIS/NIS+ server is down, the domain master periodically sends a copy of all of its source files to a backup server, called a slave.

Secure NFS Concepts

Using a distributed file system has many advantages. Client machines do not have to have their own copies of files, so resources can be kept on a single server. Different machines on your network can share files conveniently and easily However, the attributes that make file sharing so useful also make it vulnerable to security leaks.

Although NFS servers authenticate a request to share a resource by authenticating the machine making the request, the user on the machine who initiated the request is not authenticated. This can lead to security problems. For instance, a remote user on a trusted machine may be able to gain superuser privileges if superuser privileges have not been restricted when a file system was shared. This user could then impersonate the owner of this resource, changing it at will. Unauthorized users may be able to gain access to your network and may attack your network by injecting data. Or they may simply eavesdrop on network data, compromising the privacy of the data transmitted over your network.

To protect NFS networking from unauthorized users, some UNIX variants provide a service called Secure NFS that can be used to authenticate individual users on remote machines. Secure NFS is built upon Secure RPC, an authentication scheme for remote procedure calls. Secure RPC encrypts conversations using private-key encryption based on the Data Encryption Standard (DES), using a public-key encryption system for generating a common key for each conversation.

Sharing NFS Resources

You may want to share resources such as files or directories on your system with other systems on the network. For instance, you might want members of a project team to be able to use your source file of the team’s final report. Or you may have written a shell program that can index a book that you would like to make available for sharing with users on other systems. Or you might want to share your printer with users on other systems.

Technically, when you share a resource, you make it available for mounting by remote systems. You have several different ways to share resources on your machine with other systems. First, you can use one of the commands provided for sharing files, such as exportfs, share, and shareall. Second, you can automatically share resources by including lines in the /etc/exports file or the /etc/dfs/dfstab file.

The exportfs Command

Linux and HP-UX use the exportfs command to make a resource available to other users on other systems. To use this command, you must first create an entry for the file in the /etc/ exports file on your system. An example entry that allows the directory /myfiles/papers to be readable and writable by users on the machine sharlene is

 /myfiles/papers -rw sharlene

You need to be root in order to share the resource. When you want to make this file sharable, you enter the command

 # exportfs

The share Command

The share command is used by Solaris systems to make a resource on your system available to users on other systems. To do this, you must have root privileges. You can use this command to share an NFS resource. You indicate your choice of distributed file systems by using the –F option. You can restrict how clients may use your shared resources by using the –o option.

Suppose you wish to share the directory /usr/xerxes/scripts containing a set of shell scripts over NFS. You want to allow all clients read-only access except for the client jersey. Use the following command line:

 # share -F nfs -o ro, rw=jersey /usr/xerxes/scripts

You can use the share command, with no arguments, to display all the resources on your system that are currently shared. The command

 $ share -F nfs

displays all NFS resources on your system that are currently shared.

The exportfs -a Command

You may want to make multiple resources available to users at the same time. Linux and HP-UX use the exportfs command with the –a option to do this. For example, suppose you had multiple entries in the /etc/exports file such as

 /myfiles/papers -rw sharlene /myfiles/articles -rw sharlene /myfiles/presentations -rw dodger

You could make the first two resources available to users on system sharlene and the last one to users on machine dodger by using the command

 # exportfs -a

The shareall Command

You can share multiple resources simultaneously on Solaris machines with the shareall command. One way to use this command is to create an input file whose lines are share command lines for sharing particular resources. Suppose your input file is named resources and contains the following commands:

 $ cat resources share -F nfs -o ro, rw=astrid /etc/misc share -F nfs /usr/xerxes

You can share all the resources listed in this file, as specified in the share commands in the lines of the file, by typing

 # shareall resources

Automatically Sharing Resources

Sometimes you might want a resource to be available at all, or almost all, times to remote clients. You can make such a resource available automatically whenever your system starts running NFS. You do this by including a line in the /etc/exportfs file consisting of an exportfs command (Linux and HP-UX) or in the /etc/dfs/dfstab file consisting of a share command (Solaris), with the appropriate options and arguments.

For instance, if you want your directory scripts in your home directory /usr/fred to be an NFS resource on your Solaris system with read-only access to remote clients, include the following line in /etc/dfs/dfstab:

 share -F nfs -o ro /usr/fred/scripts

Unsharing NFS Resources

Sometimes you may want to stop sharing, or “unshare,” a resource, making it unavailable for mounting by other systems. For instance, you may have a directory that contains the source file of a final report of a team project. When the report has been edited by all team members, you want to keep users on other systems from accessing the source file until it has been approved by management. Or you may want to make a set of shell scripts in that directory unavailable for sharing while you update them.

You can use the unshare command to make a resource unavailable for mounting, supplying it with the resource pathname. In the case of NFS, you may also give it the resource name. For instance, to unshare the Solaris mounted directory /usr/fred/, which is an NFS resource, you use this command:

 # unshare -F nfs /usr/fred/

Note that on Solaris you can unshare only exported directories, not files. Other variants, such as Linux, allow you to unshare files. In the previous example, if there were a file in /usr/fred/ called sourcefiles, you could unshare it with the command

 # unshare -F nfs /usr/fred/sourcefiles

The exportfs -u Command

Sometimes you may want to stop sharing all currently shared resources on your system. For instance, you may have a security problem and not want users on remote systems to access your files. Linux and HP-UX allow you to prevent this with the exportfs command with the –u option. They do this slightly differently though. In HP-UX you only need to enter the command

 # exportfs -u

in order to stop sharing resources. In Linux, you must first change your current directory to /etc/exports and then issue the command, as in the following example:

 # cd /etc/exports # exportfs -u

The unshareall Command

Solaris uses the unshareall command to stop sharing all resources. Typing

 # unshareall

unshares all the currently shared resources on your system.

You can also unshare all current NFS resources on your system with this command:

 # unshareall -F nfs

Mounting Remote NFS Resources

Before being able to use a resource on a remote machine that is available for sharing, you need to mount this resource. You can use the mount command or mountall command to mount remote resources. Also, you can automatically mount remote resources by including lines in /etc/vfstab (or /etc/fstab in Linux and some older versions of HP-UX).

The mount Command

You can use the mount command to mount a remote resource. You must be a superuser to mount remote resources. You use the –F option to specify the distributed file system (except in Linux you use the –t option to specify the file system) and the –o option to specify options. You supply the pathname of the remote resource on remotesystem and the mount point where you want this remote resource mounted on your file system as arguments. You must have already used the mkdir command to set up the directory you are using as a mount point.

For instance, you can mount the remote NFS resource, with read-only permission, with pathname /usr/fred/reports at the mount point /usr/new.reports on a Solaris system by typing this:

 # mount -F nfs -o ro remotesystem:/usr/fred/reports /usr/new.reports

If the name of the resource /usr/fred/reports is REPORTS, you can mount this resource on a Linux system in the same way by typing this:

 # mount -t nfs -o ro REPORTS /usr/new.reports

When you use the mount command to mount a remote resource, it stays mounted only during your current session or until it is specifically unmounted.

The mountall Command

You can mount a combination of remote resources using the mountall command. To use mountall, you create a file containing a line for each remote resource you want to mount. This is the form of the line

 special – mountp fstype – automnt mountopts

The fields contain the following information:

Special	For NFS, the name of the server, followed by a colon, followed by the directory name on the server
Mountp	The directory where the resource is mounted
Fstype	The file system type (NFS)
Automnt	Indicates whether the entry should be automounted by /etc/mountall
Mountopts	A list of –o arguments

For instance, if you create a file called mntres with

 $ cat mntres  jersey:/usr/fred/reports   -/usr/reports  nfs  -yes  rw

and run the command

 # mountall mntres

you will mount all the remote resources listed in the file mntres at the mount points specified with the specified access options (in this example, only one resource).

If you run the command

 # mountall -F nfs mntres

you will only mount the NFS resources listed in the file mntres, which in this case is the directory /usr/fred/reports on the server jersey.

Automatic Mounting

You do not have to use the mount command each time you want to mount a remote resource. Instead, you can automatically mount a remote file system when you start running NFS (when your system enters run level 3, as is explained in Chapter 13) by placing the appropriate entries into the /etc/vfstab file (/etc/fstab on Linux).

To have a remote resource mounted automatically, first create a mount point using the mkdir command. Then insert a line in the /etc/vfstab file of the same form as is used by the mountall command.

Suppose you want to automatically mount the NFS resource /usr/tools on the server jersey when your system starts running NFS (enters run level 3). You want to give this resource read-only permissions. Assuming that you have already created the mount point /special/bin, the line you put in the /etc/vfstab file is

 jersey:/usr/tools    -/special/bin    nfs    -yes    ro

To mount resources you have just listed in the /etc/vfstab file, use this command:

 # mountall

This works because the default file used by the mountall command for listing of remote resources is /etc/vfstab.

Unmounting a Remote Resource

You may want to unmount a remote resource from your file system. For example, you may be finished working on a section of a report in which the source files are kept on a remote machine.

The umount Command

You can unmount remote resources using the umount command. To unmount an NFS resource, you supply the name of the remote server, followed by a colon, followed by the pathname of the remote resource or the mount point as an argument to umount.

To unmount the NFS resource /usr/fred/scripts, shared by server jersey, with mount point /etc/scripts, use the command

 # umount jersey:/usr/fred/scripts

or

 # umount /etc/scripts

The umountall Command

You can unmount all the remote resources you have mounted by issuing a umountall command with the appropriate options. To unmount all NFS resources, use the command

 # umountall -F nfs

Displaying Information About Shared Resources

There are several different ways to display information about shared resources, including the share command and the mount command with no options.

Using the share Command

You can use the share command to display information about the resources on your system that are currently shared by remote systems. For instance, to get information about all NFS resources on your system that are currently shared, type this:

 $ share -F nfs

Using the mount Command to Display Mounted Resources

You can display a list of all resources that are currently mounted on your system, including both local and remote resources, by running the mount command with no options. For instance,

 $ mount / on /dev/root read/write/setuid on Fri Jul 7 19:35:27 2006 /proc on /proc read/write on Fri Jul 7 19:35:29 2006 /dev/fd on /dev/fd read/write on Fri Jul 7 19:35:29 2006 /var on /dev/dsk/c1d0s8 read/write/setuid on Fri Jul 7 19:35:49 2006 /usr on /dev/dsk/c1d0s2 read/write/setuid on Mon Jul 10 08:30:27 2006 /home on /dev/dsk/c1d0s9 read/write/setuid on Mon Jul 10 08:30:35 2006 /usr/local on tools read/write/remote on Fri Jul 14 19:25:37 2006 /home/khr on /usr read/write/remote on Sat Jul 15 08:55:04 2006

The remote resources are explicitly noted (but not the machines they are mounted from). For instance, a remote resource entry for Linux would look like this:

 badri:/usr/FSF on /mnt/external type nfs (rw, addr=10.8.11.14)

and a remote resource entry on a Solaris machine would look like this:

 /users on kanchi:/store/home bg/soft/remote on Sat Jul 15 14:21:07 2006

Browsing Shared Resources

You may want to browse through a list of the NFS resources available to you on specific remote machines. For example, you may be looking for useful shell scripts available on the remote systems in your network. To display information on the NFS resources available to you on Solaris machines, use the dfshares commands. You can restrict the displayed resources to resources on a specific server.

For instance, the command

 $ dfshares -F nfs jersey RESOURCE                    SERVER     ACCESS    TRANSPORT jersey:/home/khr            jersey     -         - jersey:/var                 jersey     -         -

displays a list of all NFS resources available for sharing by machine jersey.

Linux and HP-UX use the showmount command with the –e option to provide the same type of output display For example, to see all NFS resources available for sharing by a Linux machine called kanchi, type

 # showmount -e Export list for kanchi: /internal/opt/man           (everyone) /internal/httpd/htdocs      (everyone) /internal/ftp/pub/unix/bash (everyone)

Monitoring the Use of Local NFS Resources

Before changing or removing one of your shared local resources, you may want to know which of your resources are mounted by clients. You can use the dfmounts command to determine this. When you use dfmounts to find which local NFS resources are shared, you can restrict the clients considered by listing as arguments the clients you are interested in. For instance, by restricting the server michigan to the clients oregon and arizona, you will find this:

 # dfmounts -F nfs oregon arizona RESOURCE             SERVER    PATHNAME    ACCESS    CLIENTS michigan:/tools      michigan  /tools      rw        oregon michigan:/usr/share  michigan  usr/share   ro        oregon, arizona michigan:/notes      michigan  /notes      ro        arizona