[smarttouch]

File systems can be shared across a network by any of the methods we have discussed above. We can briefly note here the correspondence of commands and methods for achieving network sharing.

With AFS and DCE/DFS, used mainly on Unix-like hosts, the security model is such that a computer becomes part of a cell or domain. Within such a cell, disk partitions are referred to as volumes. These can be replicated and shared with other computers. AFS cells on other server hosts can be attached to client hosts using the afsd program. A local cell can be published to the rest of the AFS speaking network by adding its attributes to a database. The resulting seamless file tree is visible under /afs. The visibility of files in this model is controlled by the Access Control Lists.

Unix-like hosts use NFS to share filesystems, by running the daemons (e.g. rpc.mountd and rpc.nfsd). Filesystems are made available for sharing by adding them to the file /etc/exports, on most systems, or confusingly to /etc/dfs/dfstab on SVR4 based Unix. The syntax in these files is particular to the flavor of the Unix-like operating system one is using. With some operating systems, using /etc/exports, it is necessary to run the command exportfs –a to make the contents of the export file visible to the daemons which control access. On SVR4 systems, like Solaris, there is a command called share for exporting filesystems, and the file /etc/dfs/dfstab is just a shell script containing a lot of share commands.

e.g. allhosts=nomad:vger:nomad.domain.country:vger.doma in.country
share -F nfs -o rw=$allhosts /site/server/local

Here the command shareall is the equivalent for exporting all filesystems in this file. It simply runs a shell script containing all such commands. The example above makes the directory tree /iu/server/local available to the hosts nomad and vger.

Note that due to different name services implementations and their various behaviors, it is often necessary to use both the unqualified and fully qualified names of hosts when sharing.On the client or receiving end, we attach a shared file system to a host by ‘mounting’ it. NFS filesystems are mounted in exactly the same way as they mount a local disk, i.e. with the mount command, e.g.

mkdir -p /site/server/local
mount server:/site/server/local /site/server/local

Here we create a directory on which to mount a foreign filesystem and then mount it on a directory which has the same name as the original on the server. The original name and the new name do not have to be the same, but there is a point to this which we shall return to later. Assuming that the server-host granted us the right to mount the filesystem on our host, we now have access to the remote filesystem, as though it were a local disk. The only exception is the super user root, who is granted the access rights of a user called nobody. The point of this is that the administrator on the client host is not necessarily the administrator on the server host, and has no obvious right to every users’ files there. This mapping can be overridden if convenience outweighs the minor security it adds.

Windows filesystems on a server are shared, either using the GUI, or by executing the command

net share alias=F:\filetree

On the client side, the file tree can then be ‘mounted’ by executing the command

net use X: \\serverhost\alias

This attaches the remote file tree, referenced by the alias, to Windows drive X:. One of the logistical difficulties with the Windows drive model is that drive associations are not constant, but might change when new hardware is detected.

Drive associations can be made to persist by adding a flag net use X: \\serverhost\alias /persistent:yes to the mount command. This is not a perfect solution, but it works.