CIFS Shares
A shared resource, or share, is a local resource on a server
that is accessible to CIFS clients on the network. For the Solaris
CIFS service, a share is typically a directory. Each share is identified
by a name on the network. A CIFS client sees the share
as a complete entity on the CIFS server, and does not see
the local directory path to the share on the server.
Note - A share and a directory are independent entities. Removing a share does
not affect the underlying directory.
Shares are commonly used to provide network access to home directories on
a network file server. Each user is assigned a home directory. A
share is persistent and remains defined regardless of whether users are connected
to the server.
The Solaris CIFS service provides a special kind of share called an
autohome CIFS share. An autohome share is a transient share of a user's
home directory that is created when a user logs in and removed
when the user logs out.
When a user browses the system, only statically defined shares and his
autohome share will be listed.
Autohome Shares
The autohome share feature eliminates the administrative task of defining and maintaining
home directory shares for each user that accesses the system through the
SMB protocol. The system creates autohome shares when a user logs in,
and removes them when the user logs out. This process reduces the
administrative effort needed to maintain user accounts, and increases the efficiency of
service resources.
For example, if /home is a home directory that contains subdirectories for
users bob and sally, you can manually define the shares as follows:
- bob
/home/bob
- sally
/home/sally
However, defining and maintaining directory shares in this way for each user
is inconvenient. Instead, you can use the autohome feature.
Note - The Solaris CIFS client does not support autohome shares.
To configure the autohome feature, you need to specify autohome share rules.
For example, if a user's home directory is /fort/sally, the autohome path
is /fort. The temporary share is named sally. Note that the user's
home directory name must be the same as the user's login name.
See How to Create a Specific Autohome Share Rule.
When a user logs in, the Solaris CIFS service looks for a
subdirectory that matches the user's name based on any rules that have
been specified. If the service finds a match and if that share
does not already exist, the subdirectory is added as a transient share.
When the user logs out, the service removes that transient share.
Some Windows clients log a user out after 15 minutes of inactivity,
which results in the autohome share disappearing from the list of defined
shares. This behavior is expected for CIFS autohome shares. Even after a
CIFS autohome share is removed, the share reappears when the user attempts
to access the system (for example, in an Explorer window).
Note - All autohome shares are removed when the Solaris CIFS service is restarted.
Autohome Entries
The Solaris CIFS service can automatically share home directories when a CIFS
client connects. The autohome map file, /etc/smbautohome, uses the search options and
rules to determine whether to share a home directory when a CIFS
client connects to the service.
For example, the following entries specify the autohome rules for a particular
environment:
+nsswitch dn=ads,dn=sun,dn=com,ou=users
jane /home/?/& dn=ads,dn=sun,dn=com,ou=users
The nsswitch autohome entry uses the naming service to match users to
home directories. The second autohome entry specifies that the home directory for
user jane is /home/j/jane.
Autohome Map Entry Format
A map entry, also referred to as a mapping, uses the following
format:
key location [ container ]
key is a user name, location is the fully qualified path for
the user's home directory, and container is an optional AD container.
If you intend to publish the share in AD, you must specify
an AD container name, which is specified as a comma-separated list of
attribute name-value pairs. The attributes use the Lightweight Data Access Protocol (LDAP) distinguished name (DN) or
relative distinguished name (RDN) format.
The DN or RDN must be specified in LDAP format by using
the following attribute types:
cn= represents the common name
ou= represents the organizational unit
dc= represents the domain component
Note - The attribute type that is used to describe an object's RDN is
called a naming attribute.
AD uses the naming attributes as follows:
cn for the user object class
ou for the OU (organizational unit) object class
dc for the domainDns object class
Autohome Map Key Substitution
The autohome feature supports the following wildcard substitutions for the value of
the key field:
The ampersand character (&) is expanded to the value of the key field for the entry in which it occurs. In the following example, & expands to jane:
jane /home/&
The question mark character (?) is expanded to the value of the first character in the key field for the entry in which it occurs. In the following example, the path is expanded to /home/jj/jane:
jane /home/??/&
Wildcard Rule
When supplied in the key field, the asterisk character (*) is recognized
as the “catch-all” entry. Such an entry matches any key not previously
matched.
For example, the following entry would map any user to a home
directory in /home in which the home directory name was the same
as the user name:
* /home/&
Note - The wildcard rule is only applied if an appropriate rule is not
matched by another map entry.
nsswitch Map
The nsswitch map is used to request that the home directory be
obtained from a password database, such as the local, NIS, or LDAP
database. If an AD path is appended, it is used to publish
shares.
+nsswitch
Like the “catch-all” entry, the nsswitch map is only searched if an
appropriate rule is not matched by another map entry.
Note - The wildcard and nsswitch rules are mutually exclusive. Do not include an
nsswitch rule if a wildcard rule has already been defined.