|HP-UX Reference > S
HP-UX 11i Version 3: February 2007
share_nfs: share — make local NFS file systems available for mounting by remote systems
The share utility makes local file systems available for mounting by remote systems.
If no argument is specified, then share displays all file systems currently shared, including NFS file systems and file systems shared through other distributed file system packages.
The following options are supported:
The following operands are supported:
The access_list Argument
The access_list argument is used in many of the options described above. The access_list is a colon-separated list whose components may be any number of the following.
The following example shows the /export file system shared with logging enabled:
example% share -o log /export
The default global logging parameters are used since no tag identifier is specified. The location of the log file, as well as the necessary logging work files, is specified by the global entry in /etc/nfs/nfslog.conf.
If the async option is used, an unreported data loss may occur ONLY on a write and ONLY if the NFS server experiences a failure after the write reply has been sent to the client. Specifically, blocks which have been queued for the server's disk, but have not yet been written to the disk may be lost.
You cannot export either a parent directory or a subdirectory of an exported directory that resides within the same file system. It is not allowed, for instance, to export both /usr and /usr/local if both directories reside on the same disk partition.
If the sec= option is presented at least once, all uses of the window=, rw, ro, rw=, ro=, and root= options must come after the first sec= option. If the sec= option is not presented, then sec=sys is implied.
If one or more explicit sec= options are presented, sys must appear in one of the options mode lists for accessing using the AUTH_SYS security mode to be allowed. For example:
share -F nfs /var share -F nfs -o sec=sys /var
will grant read-write access to any host using AUTH_SYS, but
share -F nfs -o sec=dh /var
will grant no access to clients that use AUTH_SYS.
Access checking for the window=, rw, ro, rw=, and ro= options is done per NFS request, instead of per mount request.
Combining multiple security modes can be a security hole in situations where the ro= and rw= options are used to control access to weaker security modes. In this example,
share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
an intruder can forge the IP address for hosta (albeit on each NFS request) to side-step the stronger controls of AUTH_DES. Something like:
share -F nfs -o sec=dh,rw,sec=sys,ro /var
is safer, because any client (intruder or legitimate) that avoids AUTH_DES will only get read-only access. In general, multiple security modes per share command should only be used in situations where the clients using more secure modes get stronger access than clients using less secure modes.
If rw=, and ro= options are specified in the same sec= clause, and a client is in both lists, the order of the two options determines the access the client gets. If client hosta is in two netgroups - group1 and group2- in this example, the client would get read-only access:
share -F nfs -o ro=group1,rw=group2 /var
In this example hosta would get read-write access:
share -F nfs -o rw=group2,ro=group1 /var
If within a sec= clause, both the ro and rw= options are specified, for compatibility, the order of the options rule is not enforced. All hosts would get read-only access, with the exception to those in the read-write list. Likewise, if the ro= and rw options are specified, all hosts get read-write access with the exceptions of those in the read-only list.
The ro= and rw= options are guaranteed to work over UDP and TCP but may not work over other transport providers.
The root= option with AUTH_SYS is guaranteed to work over UDP and TCP but may not work over other transport providers.
The root= option with AUTH_DES is guaranteed to work over any transport provider.
There are no interactions between the root= option and the rw, ro, rw=, and ro= options. Putting a host in the root list does not override the semantics of the other options. The access the host gets is the same as when the root= options is absent. For example, the following share command will deny access to hostb:
share -F nfs -o ro=hosta,root=hostb /var
The following will give read-only permissions to hostb:
share -F nfs -o ro=hostb,root=hostb /var
The following will give read-write permissions to hostb:
share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
If the file system being shared is a symbolic link to a valid pathname, the canonical path (the path which the symbolic link follows) will be shared. For example, if /export/foo is a symbolic link to /export/bar (/export/foo -> /export/bar), the following share command will result in /export/bar as the shared pathname (and not /export/foo).
example# share -F nfs /export/foo
Note that an NFS mount of server:/export/foo will result in server:/export/bar really being mounted.
This line in the /etc/dfs/dfstab file will share the /disk file system read-only at boot time:
share -F nfs -o ro /disk
Note that the same command entered from the command line will not share the /disk file system unless there is at least one file system entry in the /etc/dfs/dfstab file.