Solaris Naming Administration Guide

Creating File Contexts With an Input File

The input file supplies the names and values to be bound in the context of composite_name. Its format is based upon and similar, but not identical, to the format of indirect automount maps. The input file contains one or more entries with the form:

name [options] [location...]


For each entry a reference to the mount locations and the corresponding mount options is bound to the name composite_name/name.

If options and location are both omitted, then no reference is bound to composite_name/name. Any existing reference is unbound.

For example, suppose you want kuanda's file system to be an NFS mount of the directory /export/home/kuanda from host altair as shown in Figure 22-4. The command would be run as follows:

% fncreate_fs -f infile user/kuanda/fs

With infile containing:

. altair:/export/home/kuanda

To set up a more complex file system distributed over more than one server as shown in Figure 22-5, run the command

% fncreate_fs -f infile org/sales/fs

with infile containing

tools/db	 	altair:/export/db
project		 	altair:/export/proj
project/lib             altair:/export/lib
project/src	 	deneb:/export/src

To change the NFS mounts for project and its subcontexts src and lib to be read-only, you can change infile as follows:

tools/db 	 			svr1:/export/db
project	      -ro			svr1:/export/projproject/lib altair:/export/lib
project/src	 			svr2:/export/src

The -ro is unnecessary in the third and fourth lines because src and lib are subcontexts of project, they will inherit the -ro mount option from above.

The following input file would make all of the mounts read-only except for org/sales/fs/project/src.

.	 		-ro
tools/db 			 	svr1:/export/db
project	 				svr1:/export/proj
project/lib altair:/export/lib
project/src         -rw	         svr2:/export/src