2.4 Filesystems

to the actual disk blocks which are associated with the file. The inode contains essential information needed to locate a file on the disk.

The top or start of the Unix file tree is called the root filesystem or ‘/’. Although the details of where common files are located differ for different versions of Unix, some basic features are the same.

The file hierarchy

The main subdirectories of the root directory together with the most important file are shown below. Their contents are as follows.

•/bin Executable (binary) programs. On most systems this is a separate directory to /usr/bin. In SunOS, this is a pointer (link) to /usr/bin.

•/etc Miscellaneous programs and configuration files. This directory has become very messy over the history of Unix and has become a dumping ground for almost anything. Recent versions of Unix have begun to tidy up this directory by creating subdirectories /etc/mail, /etc/inet etc.

•/usr This contains the main meat of Unix. This is where application software lives, together with all of the basic libraries used by the OS.

•/usr/bin More executables from the OS.

•/usr/sbin Executables that are mainly of interest to system administrators.

•/usr/local This is where users’ custom software is normally added.

•/sbin A special area for (often statically linked) system binaries. They are placed here to distinguish commands used solely by the system administrator from user commands, and so that they lie on the system root partition, where they are guaranteed to be accessible during booting.

•/sys This holds the configuration data which go to build the system kernel. (See below.)

•/export Network servers only use this. This contains the disk space set aside for client machines which do not have their own disks. It is like a ‘virtual disk’ for diskless clients.

•/dev and /devices A place where all the ‘logical devices’ are collected. These are called ‘device nodes’ in Unix and are created by mknod. Logical devices are Unix’s official entry points for writing to devices. For instance, /dev/console is a route to the system console, while /dev/kmem is a route for reading kernel memory. Device nodes enable devices to be treated as though they were files.

•/home (Called /users on some systems.) Each user has a separate login directory where files can be kept. These are normally stored under /home by some convention decided by the system administrator.

•/root On newer Unix-like systems, root has been given a home-directory which is no longer the root of the filesystem ‘/’. The name root then loses its logic.

•/var System V and mixed systems have a separate directory for spooling. Under old BSD systems, /usr/spool contains spool queues and system data. /var/spool and /var/adm etc. are used for holding queues and system log files.

Every Unix directory contains two ‘virtual’ directories marked by a single dot and two dots.

ls -a

...

The single dot represents the directory one is already in (the current directory). The double dots mean the directory one level up the tree from the current location. Thus, if one writes

cd /usr/share cd ..

the final directory is /usr. The single dot is very useful in C programming if one wishes to read ‘the current directory’. Since this is always called ‘.’ there is no need to keep track of what the current directory really is. ‘.’ and ‘..’ are hard links to the current and parent directories, respectively.

Symbolic links

A symbolic link is a pointer or an alias to another file. The command

ln -s fromfile /other/directory/tolink

makes the file fromfile appear to exist at /other/directory/tolink simultaneously. The file is not copied, it merely appears to be a part of the file tree in two places. Symbolic links can be made to both files and directories.

A symbolic link is just a small file that does not appear explicitly to the user, and which contains the name of the real file one is interested in. Unlike Windows’s short-cuts, symbolic links cannot be seen to be files with a text editor; they are handled specially at the level of the operating system. Application programs can choose whether they want to treat a symbolic link as a separate file object, or simply as an alias to the file it points to. If we remove the file a symbolic link points to, the link remains – it just points to a non-existent file.

Hard links

A hard link is a duplicate directory reference to an inode in the filesystem. It is in every way equivalent to the original file reference. If a file is pointed to by a number of hard links, it cannot be removed until all of the links are removed. If a file has n hard links, all of them must be removed before the file can be removed.

The number of hard links to a file is stored in the filesystem index node for the file. A hard link is created with the ln command, without the -s option. Hard links are, in all current Unix-like operating systems, limited to aliasing files on the same filesystem. Although the POSIX standard specifies the possibility of making hard links across disk partitions with separate filesystems, this has presented an insurmountable technical difficulty because it would require inodes to have a global numbering scheme across all disk partitions. This would be an inefficient overhead for an additional functionality of dubious utility, so currently this has been ignored by filesystem designers.

File access control

In order to restrict privilege to files on the system, and create the illusion of a virtual host for every logged-on user, Unix records information about who creates files and also who is allowed to access them later. Unix makes no policy on what names files should have: a file can have any name, as long as it does not contain illegal characters such as forward-slash. A file’s contents are classified by so-called magic numbers which are 16 or 32 bit codes kept at the start of a file and defined in the magic number file for the system. Magic numbers tell the system what application a file type belongs to, or how it should be interpreted (see the Unix command file). This is in contrast to systems like Windows, where file extensions (e.g. .EXE) are used to identify file contents. Under Unix, file extensions (e.g. .c) are only discretionary.

Each user has a unique username or loginname together with a unique user id or uid. The user id is a number, whereas the login name is a text string – otherwise the two express the same information. A file belongs to user A if it is owned by user A. User A then decides whether or not other users can read, write or execute the file by setting the protection bits or the permission of the file using the command chmod.

In addition to user identities, there are groups of users. The idea of a group is that several named users might want to be able to read and work on a file, without other users being able to access it. Every user is a member of at least one group, called the login group and each group has both a textual name and a number (group id). The uid and gid of each user is recorded in the file /etc/passwd (see chapter 6). Membership of other groups is recorded in the file /etc/group or on some systems /etc/logingroup.

The following output is from the command ls -lag executed on a SunOS type machine.

The first column is a textual representation of the protection bits for each file. Column two is the number of hard links to the file, for regular files, or the number of objects contained in a subdirectory. The third and fourth columns are the user name and group name and the remainder show the file size in bytes and the creation date. Notice that the directories /bin and /sys are symbolic links to other directories.

There are sixteen protection bits for a Unix file, but only twelve of them can be changed by users. These twelve are split into four groups of three. Each three-bit number corresponds to one octal number.

The leading four invisible bits give information about the type of file: is the file a plain file, a directory or a link etc. In the output from ls this is represented by a single character: -, d or l.

The next three bits set the so-called s-bits and t-bit which are explained below. The remaining three groups of three bits set flags which indicate whether a file can be read r, written to w or executed x by (i) the user who created them, (ii) the other users who are in the group the file is marked with, and (iii) any user

at all.

For example, the permission

Type Owner Group Anyone

d rwx r-x ---

tells us that the file is a directory, which can be read and written to by the owner, can be read by others in its group, but not by anyone else.

Note about directories. It is impossible to cd to a directory unless the x bit is set. That is, directories must be ‘executable’ in order to be accessible.

Here are some examples of the relationship between binary, octal and the textual representation of file modes.

Binary Octal Text

It is well worth becoming familiar with the octal number representation of these permissions, since they are widely used in literature.

chmod

The chmod command changes the permission or mode of a file. Only the owner of the file or the superuser can change the permission. Here are some examples of its use. Try them.

#make write-able for everyone chmod a+w myfile

#add the user (owner) ’execute’ flag for directory chmod u+x mydir/

#open all files for everyone

chmod 755 *

#set the s-bit on my-dir’s group chmod g+s mydir/

#descend recursively into directory opening all files chmod -R a+r dir

New file objects: umask

When a new file is created, the operating system must decide what default protection bits to set on that file. The variable umask decides this. umask is normally set by each user in his or her .cshrc file (see next chapter). For example

umask only removes bits, it never sets bits which were not already set in 666. For instance

Making programs executable

A Unix program is normally executed by typing its pathname. If the x execute bit is not set on the file, this will generate a ‘permission denied’ error. This protects the system from interpreting nonsense files as programs. To make a program executable for someone, you must therefore ensure that they can execute the file, using a command like

chmod u+x filename

This command would set execute permissions for the owner of the file;

chmod ug+x filename

would set execute permissions for the owner and for any users in the same group as the file. Note that script programs must also be readable in order to be executable, since the shell has to interpret them by reading.

chown and chgrp

These two commands change the ownership and the group ownership of a file. For example:

chown mark ~mark/testfile

chgrp www ~mark/www/tmp/cgi.out

In newer implementations of chown, we can change both owner and group attributes simultaneously, by using a dot notation:

chown mark.www ~mark/www/tmp/cgi.out

Only the superuser can change the ownership of a file. This is to prevent users from being able to defeat quota mechanisms. (On some systems, which do not implement quotas, ordinary users can give a file away to another user but not get it back again.) The same applies to group ownership.

Making a group

The superuser creates groups by editing the file /etc/group. Normally users other than root cannot define their own groups. This is a historical weakness in Unix, and one which no one seems to be in a hurry to change. It is possible to ‘hack’ a solution to this which allows users to create their own groups. The format of the group file is:

group-name:: group-number: comma-separated-list-of-users

The Unix group mechanism is very convenient, but poorly conceived. ACLs go some way to redressing its shortcomings (see below) but at an enormous price, in terms of computer resources. The group mechanism is fast and efficient, but clumsy for users.

s-bit and t-bit (sticky bit)

Apart from the read, write and execute file attributes, Unix has three other flags. The s- and t- bits have special uses. They are set as follows:

The effect of these bits differs for plain files and directories and also differs between different versions of Unix. Check particularly the manual page man sticky on each system. The following is common behavior.

For executable files, the setuid bit tells Unix that regardless of who runs the program it should be executed with the permissions and rights of the owner of the file. This is often used to allow normal users limited access to root privileges. A setuid-root program is executed as root for any user. The setgid bit sets the group execution rights of the program in a similar way.

In BSD Unix, if the setgid bit is set on a directory then any new files created in that directory assume the group ownership of the parent directory and not the login group of the user who created the file. This is standard policy under System V.

A directory for which the sticky bit is set restricts the deletion of files within it. A file or directory inside a directory with the t-bit set can only be deleted or renamed by its owner or the superuser. This is useful for directories like the mail spool area and /tmp which must be writable to by everyone, but should not allow a user to delete another user’s files.

Access control lists

ACLs, or access control lists are a modern replacement for file modes and permissions. With access control lists we can specify precisely the access rights to files for each user individually. Although ACLs are functionally superior to the old Unix group ownership model, experience shows that they are too complicated for most users in practice. Also, the overhead of reading and evaluating ACLs places a large performance burden on a system.

Previously the only way to grant access to a file to a known list of users, was to make a group of those users, and use the group attribute of the file. With ACLs this is no longer necessary. ACLs are both a blessing and a nightmare. They provide a functionality which has long been missing from operating systems, and yet they are often confusing and even hopelessly difficult to understand in some filesystems. One reason for this is when filesystems attempt to maintain compatibility with older protection models (e.g. Unix/Posix permissions and ACLs, as in Solaris). The complex interactions between creation masks for Unix permissions and inherited properties of ACLs make ACL behavior non-intuitive. Trying to obtain the desired set of permissions on a file can be like a flirtation with the forces of mysticism. This is partly due to the nature of the library interfaces and partly due to poor or non-existent documentation.

ACLs existed in several operating systems prior to Unix, but were introduced to Unix in the DOMAIN OS by Apollo, and were later adapted by Novell, HP and other vendors. A POSIX standard for ACLs has been drafted, but as of today there is no adopted standard for ACLs and each vendor has a different set of incompatible commands and data-structures. Sun Microsystems’ Solaris implementation for NFS3 is based on the POSIX draft and includes ACLs. We shall follow Solaris ACLs in this section. GNU/Linux and the BSD operating systems do not have ACLs at all. If we grant access to a file which is shared on the network to a machine which doesn’t support ACLs, they are ignored. This limits their usefulness in most cases.

ACLs are literally lists of access rights. Each file has a list of data structures with pairs of names and permissions:

Figure 2.3: The standard permission model for file objects in Unix and Windows.

An ACL is specified by saying what permissions we would like to grant and which user or group of users the permissions should apply to. An ACL can grant access or deny access to a specific user. Because of the amount of time required to check all the permissions in an ACL, ACLs slow down file search operations. Under Solaris, the commands to read and write ACLs have the cumbersome names

•getfacl file Examine the ACLs for a file.

•setfacl file -s permission Set ACL entries for a file, replacing the entire list.

•setfacl file -m permission Set ACL entries for a file, adding to an existing list.

For example, if we create a new file, it ends up with a default ACL which is based upon the Unix umask value and any ACL masks which are set for the parent directory. Suppose umask is 077, and no directory ACLs are set, giving minimal rights to others:

mercury% touch testfile

mercury% getfacl testfile

#file: testfile

#owner: mark

#group: iugroup user::rw-

This tells us that a new file is created with read/write permission for the owner (mark) of the file, and no other rights are granted. To open the file for a specific user demos, one writes

mercury% setfacl -m user:demos:rwtestfile

mercury% getfacl testfile

#file: testfile

#owner: mark

#group: iugroup user::rw-

user:demos:rw- #effective:---

To open a file for reading by a group iugroup, except for one user called robot, one would write:

mercury% setfacl -m group:iugroup:r--,user:robot:--- testfile

mercury% getfacl testfile

#file: testfile

#owner: mark

#group: iugroup user::rw-

user:robot:--- #effective:---

user:demos:rw- #effective:---

group::--- #effective:---

group:iugroup:r-- #effective:---

mask:---

other:---

Notice that this is accomplished by saying that the group has read permission whilst the specific user should have no permissions.

2.4.2Windows file model

The Windows operating system supports a variety of legacy filesystems for backward compatibility with DOS and Windows 9x. These older filesystems are insecure, in the sense that they have no mechanisms for restricting access to files. The filesystem NTFS was introduced with NT in order to solve this problem. The filesystem has gone through a number of revisions and no doubt will go through many more before it reaches constancy.

NTFS, like the Unix file system, is a hierarchical file system with files and directories. Each file or directory has an owner, but no group membership. Files do not have a set of default permission bits, as does Unix; instead they all have full-blooded ACLs, which assign a set of permission bits to a specific user. NTFS ACLs are similar to other access control list models, in filesystems such as the AFS and DCE/DFS. They have all of the flexibility and all of the confusions which accompany ACLs, such as inheritance of attributes from parent directories and creation masks. The NTFS file system is indexed by a master file table, which serves an analogous function to Unix’s inodes, though the details are somewhat different.

Filesystem layout

Drawing on its DOS legacy, Windows treats different disk partitions as independent floppy disks, labelled by a letter of the alphabet:

A: B: C: D: ...

For historical reasons, drive A: is normally the diskette station, while drive C: is the primary hard disk partition. Other drive names are assigned at random, but often H: is reserved for partitions containing users’ home directories. Unlike Unix, different devices are not sewn seamlessly into a unified file tree, though this will probably change in a future release of Windows. Originally, DOS chose to deviate from its Unix heritage by changing the subdirectory separator from / to \. Moreover, since each device is treated as a separate entity, there is a root directory on every disk partition:

A:B: C: ...

and one has a notion of current working drive, as well as current working directory. These distinctions often cause confusion amongst users who work with both Unix and Windows.

The layout of the Windows filesystem has changed through the different versions, in an effort to improve the structure. This description relates to NT 4.0. The system root is usually stored in C:\WinNT and is generally referred to by the system environment variable %SystemRoot%.

•C:\I386 This directory contains binary code and data for the Windows operating system. This should normally be left alone.

•C:\Program Files This is Windows’s official location for new software. Program packages which you buy should install themselves in subdirectories of this directory. More often than not they choose their own locations, however, often with a distressing lack of discipline.

•C:\Temp Temporary scratch space, like Unix’s /tmp.

•C:\WinNT This is the root directory for the Windows system. This is mainly for operating system files, so you should not place new files under this directory yourself unless you really know what you are doing. Some software packages might install themselves here.

•C:\WinNT\config Configuration information for programs. These are generally binary files so the contents of Windows configuration files is not very interesting.

•C:\WinNT\system32 This is the so-called system root. This is where most system applications and data-files are kept.

File extensions

Whereas files can go by any name in Unix, Microsoft operating systems have always used the concept of file extensions to identify special file types. For example:

file.EXE An executable program

file.DOC Word document

file.JPG Graphic file format

Links and shortcuts

Like Unix, Windows also has ways of aliasing files in the filesystem. Windows has hard links, or duplicate entries in the master file table, allowing one to associate several names with a given file. This is not a pointer to a file, but an alternative entry point to the same file. Although the filesystem structure of NTFS is different from the Unix filesystem, the idea is the same. Hard links are created from the POSIX compatibility subsystem, using the traditional Unix command name ln. As with Unix, hard links can only be made to files on the same disk partition. Most users will not use these hard links, however.

Windows also has short cuts. A short cut is a small file which contains the name of another file, like a short script. It is normally used for aliasing scripts or programs. Unlike Unix’s symbolic links, short cuts are not handled transparently by the operating system, they are actual files which can be opened with a text editor. They must be read and dealt with at the application level. Short cuts can be given any name, but they always have the file extension .LNK. This suffix is not visible in the graphical user interface. They are created from the graphical user interface by right-clicking on the item one wishes to obtain a pointer to.

Unix compatibility packages like Cygwin32 use short cuts to emulate symbolic links. However, since short cuts work at the application level, what one package does with a short cut is not guaranteed to apply to other software, so the usefulness of short cuts is limited.

Access control lists

Windows files and directories have the following attributes. Access control lists are composed of access control entries (ACEs) which consist of these.

The read, write and execute flags have the same functions as their counterparts in Unix. The execute flag is always set on .EXE files. The additional flags allow configurable behavior, where behavior is standardized in Unix. The delete flag determines whether or not a particular user has permission to delete an object (note that a user which has write access to the file can destroy its contents independently of this). The permission and ownership flags likewise determine whether or not a specified user can take ownership or modify the permissions on a file.

Access control lists, or Access control entries are set and checked with either the Windows Explorer program (File/Properties/Security/Permissions menu) or the cacls command. This command works in more or less the same way as the POSIX setfacl command, but with different switches. The switches are

/G Grant access to user.

/E Edit ACE instead of replacing.

/T Act on all files and subdirectories.

/R Revoke (remove) access rights to a user.

/D Deny access rights to a given user.

For example:

hybrid> CACLS testfile

C:\home\mark\testfile BUILTIN\Administrators:F Everyone:C

MT AUTHORITY\SYSTEM:F

hybrid> CACLS testfile /G ds:F

Are you sure(Y/N)?

hybrid> CACLS testfile C:\home\mark\testfile HYBRID\ds:F

In this example the original ACL consisted of three entries. We then replace it with a single entry for user ds on the local machine HYBRID, granting full rights.

The result is shown in the last line. If, instead of replacing the ACE, we want to supplement it, we write

hybrid> CACLS testfile /E /G mark:R {\var wait for 30 seconds}

Are you sure(Y/N)?

hybrid> CACLS testfile C:\home\mark\testfile HYBRID\ds:F

HYBRID\mark:R

New files: inheritance

Although the technical details of the NTFS and its masking schemes are not well documented, we can note a few things about the inheritance of permissions. In the absence of any ACL settings on a parent directory, a new file is created, granting all rights to all users. If the parent directory has an ACL, then a new file inherits that ACL at the time of its creation. When a file is moved, it keeps its NTFS permissions, but when a file is copied, the copy behaves like a new file, inheriting the attributes of its new location.

2.4.3Network filesystem models

Unix and Windows have two of the most prevalent filesystem interfaces, apart from DOS itself (which has only a trivial interface), but they are both stunted in their development. In recent years, filesystem designers have returned to an old idea which dates back to a project from Newcastle University, called the Newcastle Connection, an experimental distributed filesystem which could link together many computers seamlessly into a single file tree [35]. To walk around the disk resources of the entire network, one simply used cd to change directory within a global file tree.

This idea of distributed filesystems was partially adopted by Sun Microsystems in developing their Network File System (NFS) for Unix-like operating systems. This is a distributed filesystem, for mainly local area networks. The use of open standards and a willingness to allow other vendors to use the technology quickly made NFS a de-facto standard in the Unix world, overtaking alternatives like RFS. However, owing to vendor disagreement, the Network File System has been limited to the lowest common denominator Unix filesystem-model. Vendor-specific improvements are available, but these do not work in a heterogeneous environment and thus NFS is relatively featureless, by comparison with the functionality available on local disk filesystems. In spite of this, there is no denying that NFS has been very effective, as is testified by the huge number of sites which use it unconditionally.

Other filesystems that are gaining in popularity include the Andrew File System (AFS), since it was released as an OpenAFS version. AFS became popular in institutions such as high energy physics laboratories that needed to share large

Table 2.4: DFS permissions. New files inherit the initial object ACL of their parent directory. These flags can be applied to named lists of users, or groups or others, in the Unix sense.

amounts of experimental data with colleagues all over the world. The local network domain model of NFS was not sufficient for this task. AFS has an Access Control List (ACL) model, thus improving on Unix file security. A further improvement came with the Distributed Computing Environment (DCE) filesystem DFS, that provided further enhancements and a sanitized ACL model (see table 2.5).

AFS and DFS have been embraced widely in this context, allowing collaborators in Japan, Europe and the United States to be connected simply by changing directory to a new country, organization and site (see section 3.8.7). These filesystems also employ Access Control Lists, based on, but not limited by, the Unix permission model (see table 2.4). AFS now has an OpenAFS implementation.

Note that the DCE/DFS filesystem is not related to Windows’s DFS filesystem, though the idea is similar.

As we can see, many of these file systems have drawn on the pioneering ideas of experimental filesystems. Today, most filesystems work in a similar way, with Unix lagging behind in sophistication, but not in functionality. Ironically, for all the flexibility that ACLs offer, they have proved to be confusing and difficult to understand and the extra functionality they provide is dwarfed by the feeling of dread which they instill in administrators and users alike. On systems with only ACLs, file permissions tend to be set inappropriately more often than on Unix-like systems. Unix’s simpler approach, while basically old and simplistic, is a more palatable and manageable alternative for all but the most sophisticated users.

Another major filesystem, in a similar vein, is the Novell Netware filesystem. This is an interesting filesystem which can also create a seamless file tree called the Novell Directory Service (NDS) within an organization. Here files

Table 2.5: AFS permissions. These flags can be applied to named lists of users, or groups but not ‘others’. Four shorthand forms also exist write=rlidwk, read=rl, all=rlidwka, and none removes an entry.

have an owner and an Access Control List, which can grant or restrict access to named users or groups. The Windows model was presumably inspired by this. The Netware idea is not unlike NFS or DFS in attempting to integrate organizations’ disks into a communal file tree, but the user interface is superior, since it is not limited by compatibility issues. However Netware forces a particular object-oriented interpretation of the network onto disks, whereas NFS does not care about the file tree structure of hosts which incorporate shared filesystems. With NFS, hosts do not have to subscribe to a global vision of shared network resources, they simply take what they want and maintain their own private file tree: each host could be kept quite different. Oddly enough, Windows did not embrace the model of seamless sharing, choosing instead to mount drives on the old DOS drive letters A:, B: etc, though it is likely that such seamless integration will come in a future version. Novell too has to deal with this antiquity, since it serves primarily Windows based machines.

While Solaris’ NFS does support its own brand of Access Control Lists, NFS cannot be used to provide inter-platform ACL functionality. Netware does support its own state of the art filesystem attributes, based on the usual object inheritance model of directories as containers for smaller containers. Each file has an owner and an ACL (see table 2.6).

The Common Internet File System (CIFS), based on Microsoft’s Server Message Block (SMB) protocols sets is yet another popular way of sharing files. Windows software and Unix’s Samba software bind together hosts using this form of Remote Procedure Call (see section 9.10).

Table 2.6: Netware 5 permissions. New file objects inherit the default permissions of their container, minus any flags in the Inherited Rights Filter/Mask (IRF). Permissions can be applied to named users or groups.

2.4.4Unix and Windows sharing

Filesystems 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.domain.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 filesystem 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 superuser 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