share Command

With this command, you can make a local file system on an NFS server available for mounting. You can also use the share command to display a list of the file systems on your system that are currently shared. The NFS server must be running for the share command to work. The NFS server software is started automatically during boot if an entry is in /etc/dfs/dfstab. The command does not report an error if the NFS server software is not running, so you must verify that the software is running.

The objects that can be shared include any directory tree. However, each file system hierarchy is limited by the disk slice or partition that the file system is located on. For instance, sharing the root (/) file system would not also share /usr, unless these directories are on the same disk partition or slice. Normal installation places root on slice 0 and /usr on slice 6. Also, sharing /usr would not share any other local disk partitions that are mounted on subdirectories of /usr.

A file system cannot be shared if that file system is part of a larger file system that is already being shared. For example, if /usr and /usr/local are on one disk slice, /usr can be shared or /usr/local can be shared. However, if both directories need to be shared with different share options, /usr/local must be moved to a separate disk slice.

You can gain access to a file system that is read-only shared through the file handle of a file system that is read-write shared. However, the two file systems have to be on the same disk slice. You can create a more secure situation. Place those file systems that need to be read-write on a separate partition or separate disk slice from the file systems that you need to share as read-only.

For information about how NFS version 4 functions when a file system is unshared and then reshared, refer to Unsharing and Resharing a File System in NFS Version 4.

Non-File-System-Specific share Options

Some of the options that you can include with the -o flag are as follows.

rw|ro

The pathname file system is shared read-write or read-only for all clients.

rw=accesslist

The file system is shared read-write for the clients that are listed only. All other requests are denied. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist has been expanded. See Setting Access Lists With the share Command for more information. You can use this option to override an -ro option.

NFS-Specific share Options

The options that you can use with NFS file systems include the following.

aclok

This option enables an NFS server that supports the NFS version 2 protocol to be configured to do access control for NFS version 2 clients. Without this option, all clients are given minimal access. With this option, the clients have maximal access. For instance, on file systems that are shared with the -aclok option, if anyone has read permissions, everyone does. However, without this option, you can deny access to a client who should have access permissions. A decision to permit too much access or too little access depends on the security systems already in place. See Using Access Control Lists to Protect UFS Files in System Administration Guide: Security Services for more information about access control lists (ACLs).

---

Note –

To use ACLs, ensure that clients and servers run software that supports the NFS version 3 and NFS_ACL protocols. If the software only supports the NFS version 3 protocol, clients obtain correct access but cannot manipulate the ACLs. If the software supports the NFS_ACL protocol, the clients obtain correct access and can manipulate the ACLs. Starting with the Solaris 2.5 release, the Solaris system supports both protocols.

---

anon=uid

You use uid to select the user ID of unauthenticated users. If you set uid to -1, the server denies access to unauthenticated users. You can grant root access by setting anon=0, but this option allows unauthenticated users to have root access, so use the root option instead.

index=filename

When a user accesses an NFS URL, the -index=filename option forces the HTML file to load, instead of displaying a list of the directory. This option mimics the action of current browsers if an index.html file is found in the directory that the HTTP URL is accessing. This option is the equivalent of setting the DirectoryIndex option for httpd. For instance, suppose that the dfstab file entry resembles the following:

share -F nfs -o ro,public,index=index.html /export/web

These URLs then display the same information:

nfs://<server>/<dir> nfs://<server>/<dir>/index.html nfs://<server>//export/web/<dir> nfs://<server>//export/web/<dir>/index.html http://<server>/<dir> http://<server>/<dir>/index.html

log=tag

This option specifies the tag in /etc/nfs/nfslog.conf that contains the NFS server logging configuration information for a file system. This option must be selected to enable NFS server logging.

nosuid

This option signals that all attempts to enable the setuid or setgid mode should be ignored. NFS clients cannot create files with the setuid or setgid bits on.

public

The -public option has been added to the share command to enable WebNFS browsing. Only one file system on a server can be shared with this option.

root=accesslist

The server gives root access to the hosts in the list. By default, the server does not give root access to any remote hosts. If the selected security mode is anything other than -sec=sys, you can only include client host names in the accesslist. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist is expanded. See Setting Access Lists With the share Command for more information.

---

Caution –

Granting root access to other hosts has wide security implications. Use the -root= option with extreme caution.

---

root=client-name

The client-name value is used with AUTH_SYS authentication to check the client's IP address against a list of addresses provided by exportfs(1B). If a match is found, root access is given to the file systems being shared.

root=host-name

For secure NFS modes, such as AUTH_SYS or RPCSEC_GSS, the server checks the clients' principal names against a list of host-based principal names that are derived from an access list. The generic syntax for the client's principal name is root@hostname. For Kerberos V the syntax is root/hostname.fully.qualified@REALM. When you use the host-name value, the clients on the access list must have the credentials for a principal name. For Kerberos V, the client must have a valid keytab entry for its root/hostname.fully.qualified@REALM principal name. For more information, see Configuring Kerberos Clients in System Administration Guide: Security Services.

sec=mode[:mode]

mode selects the security modes that are needed to obtain access to the file system. By default, the security mode is UNIX authentication. You can specify multiple modes, but use each security mode only once per command line. Each -mode option applies to any subsequent -rw, -ro, -rw=, -ro=, -root=, and -window= options until another -mode is encountered. The use of -sec=none maps all users to user nobody.

window=value

value selects the maximum lifetime in seconds of a credential on the NFS server. The default value is 30000 seconds or 8.3 hours.

Setting Access Lists With the share Command

In Solaris releases prior to 2.6, the accesslist that was included with either the -ro=, -rw=, or -root= option of the share command was restricted to a list of host names or netgroup names. Starting with the Solaris 2.6 release, the access list can also include a domain name, a subnet number, or an entry to deny access. These extensions should simplify file access control on a single server without having to change the namespace or maintain long lists of clients.

This command provides read-only access for most systems but allows read-write access for rose and lilac:

# share -F nfs -o ro,rw=rose:lilac /usr/src

In the next example, read-only access is assigned to any host in the eng netgroup. The client rose is specifically given read-write access.

# share -F nfs -o ro=eng,rw=rose /usr/src

You cannot specify both rw and ro without arguments. If no read-write option is specified, the default is read-write for all clients.

To share one file system with multiple clients, you must type all options on the same line. Multiple invocations of the share command on the same object “remember” only the last command that is run. This command enables read-write access to three client systems, but only rose and tulip are given access to the file system as root.

# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/src

When sharing a file system that uses multiple authentication mechanisms, ensure that you include the -ro, -ro=, -rw, -rw=, -root, and -window options after the correct security modes. In this example, UNIX authentication is selected for all hosts in the netgroup that is named eng. These hosts can only mount the file system in read-only mode. The hosts tulip and lilac can mount the file system read-write if these hosts use Diffie-Hellman authentication. With these options, tulip and lilac can mount the file system read-only even if these hosts are not using DH authentication. However, the host names must be listed in the eng netgroup.

# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src

Even though UNIX authentication is the default security mode, UNIX authentication is not included if the -sec option is used. Therefore, you must include a -sec=sys option if UNIX authentication is to be used with any other authentication mechanism.

You can use a DNS domain name in the access list by preceding the actual domain name with a dot. The string that follows the dot is a domain name, not a fully qualified host name. The following entry allows mount access to all hosts in the eng.example.com domain:

# share -F nfs -o ro=.:.eng.example.com /export/share/man

In this example, the single “.” matches all hosts that are matched through the NIS or NIS+ namespaces. The results that are returned from these name services do not include the domain name. The “.eng.example.com” entry matches all hosts that use DNS for namespace resolution. DNS always returns a fully qualified host name. So, the longer entry is required if you use a combination of DNS and the other namespaces.

You can use a subnet number in an access list by preceding the actual network number or the network name with “@”. This character differentiates the network name from a netgroup or a fully qualified host name. You must identify the subnet in either /etc/networks or in an NIS or NIS+ namespace. The following entries have the same effect if the 192.168 subnet has been identified as the eng network:

# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@192.168 /export/share/man
# share -F nfs -o ro=@192.168.0.0 /export/share/man

The last two entries show that you do not need to include the full network address.

If the network prefix is not byte aligned, as with Classless Inter-Domain Routing (CIDR), the mask length can be explicitly specified on the command line. The mask length is defined by following either the network name or the network number with a slash and the number of significant bits in the prefix of the address. For example:

# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@192.168.0/17 /export/share/man

In these examples, the “/17” indicates that the first 17 bits in the address are to be used as the mask. For additional information about CIDR, look up RFC 1519.

You can also select negative access by placing a “-” before the entry. Note that the entries are read from left to right. Therefore, you must place the negative access entries before the entry that the negative access entries apply to:

# share -F nfs -o ro=-rose:.eng.example.com /export/share/man

This example would allow access to any hosts in the eng.example.com domain except the host that is named rose.