Thursday Nov 08, 2007

Other SMB Related Differences

The SMB support brings a few new wrinkles to file sharing.  For example, NFS requires that a given path only be shared once while SMB allows it to be shared multiple times. This is supported via the resource names as described in earlier articles.  There are a couple of other differences that will be visible to administrators:

SMB shares are resource name based while NFS shares are path based 

While NFS shares appear on the client relative to their paths, SMB shares end up flattening the name space and using the resource name as the way to find the data. What this means to the end user is that a file system hierarchy such as would be generated with ZFS won't appear as a directory hierarchy on the client when accessed via SMB.  For example, consider the following ZFS hierarchy:

zfs create data/user1
zfs create data/user2
zfs create data/user2/database
zfs set sharenfs=on data

When seen from an NFS client using the /net/host mechanism, will appear as a full directory tree:


When using SMB, things are a bit different:

zfs set sharesmb=on data

From a Windows browser, you will see:


as three separate shares that can be mapped (or accessed). That is, they are all at the same level and attempting to go into the directory database in data_user2 won't get you to the data_user2_database share.

Sharing parent or child directories

NFS mandates that if a path is shared, then it is not also possible to share its parent or any of its subdirectories if they are on the same file system. SMB, on the other hand, expects to be able to do this. Sharemgr will allow you to share a parent or child directory if at least one protocol that is enabled for the group supports it. If not do, an error occurs.

In the case where a protocol does support it, the share will only be done for that protocol and an indication is made when the sharemgr show -vp command is run. A "not-shared-with=[protocol]" will be added to the line displaying the share/resource.

Autohome shares

The Solaris SMB implementation concept of autohome shares can result in shares being created dynamically and not being stored in a configuration repository. While this is will appear in sharemgr output the same as a transient share for NFS (share -F nfs /path or sharemgr add-share -t -s /path group), the SMB autohome shares are not created directly by administrator action.

Share command output

The output of the share command works as it always has and shows the paths that are shared by the specified protocol. Currently, it only shows one entry for a path shared via SMB that has multiple resources asssigned. Share defaults to displaying NFS shares. To show SMB shares, use share -F smb. There is currently a limitation that only one instance of the SMB path is displayed via "share" even if there are multiple resource names defined.

Wednesday Nov 07, 2007


ZFS users can manage SMB shares similar to the way they manage NFS shares. A new ZFS property, sharesmb, has been added that can be used to enable or disable SMB sharing on ZFS datasets. In general, it works the same as it does with NFS, but a few differences will be visible to users.

The simple case

Consider a ZFS pool "homes" with homes/user01 and homes/user02.  These can be shared via SMB by setting the sharesmb property. In the simplest case, zfs set sharesmb=on homes will start sharing while zfs set sharesmb=off homes will stop sharing. Using sharemgr to display the result shows one of the differences that does occur:

$ sharemgr show -vp zfs
zfs   nfs=() smb=()

 Note that there is a resource name assigned to each dataset. Since SMB requires a resource name, the simple case of sharesmb will create a name from the dataset name by replacing the disallowed characters ('/' in this case) with an underscore '_' character.

If we expand the above example by creating a new dataset under user02 with zfs create homes/user02/db, the output of sharemgr show will be:

$ sharemgr show -vp zfs
zfs   nfs=()

 A more complex case

Sometimes the dataset configuration may be deeper than the previous example and the resource names can get a bit long. The sharesmb implementation allows for changing the name to be used. Datasets that inherit the sharesmb property will use the new name as a prefix that replaces the dataset prefix.  For example, if the above example used a more global zpool "data" with homes being a child of data, the resource names would be prefxed with "data_" even if the data/homes dataset was given a mountpoint of /homes.  That is, the output of show would be:

$ sharemgr show -vp zfs
zfs   nfs=()

If it is preferred to have /data/homes have a resource name of homes, use sharesmb=name=homes rather than just setting sharesmb=on. For example:

$ zfs set sharesmb=name=homes data/homes
$ sharemgr show -vp zfs
zfs   nfs=()


It is also possible to set any SMB share specific properties via sharesmb. Multiple resource names are also supported for SMB shares. The basic syntax for the sharesmb property is:


where <property-lists> is a comma separated list of <property-list>. A <property-list> is a comma separted list of SMB share properties with an optional name=resource pseudo-property in front of it. So, if you use sharesmb=name=homes,name=maisons,ad-container=cn=Other when setting up the SMB sharing, each dataset will be shared with two resource names, homes and maisons.


$ sharemgr show -vp zfs
zfs   nfs=()
                   maisons=/homes   smb=(ad-container=cn=Other)
                   maisons_user02_db=/homes/user02/db    smb=(ad-container=cn=Other)


Tuesday Nov 06, 2007

Enhanced Resource Names for CIFS

With the putback of SMB functionality in sharemgr, the concept of resources has been significantly enhanced. The first enhancement is that resource names are now full objects within sharemgr. This was necessary in order to fully map SMB functionality into the framework. Second, there can be multiple resources associated with a share.

For SMB, a sharemgr resource implements an SMB share name. SMB allows sharing the same path under multiple share names, each with potentially different properties associated with it. This is what lead to supporting multiple resources for each share. With NFS, the same resource names may be used but the protocol does not really support the concept so they are treated simply as alternate names for the share.

The names allowed for resources are stored internally in UTF-8 after conversion from the locale in effect when the name is created. There are some limitations in what characters may be in a resource name due to restrictions imposed by the SMB environment.  Basically, names may contain any characters except for:

    " / \\ [ ] : | < > + ; , ? \* = <tab>

Spaces are allowed but require careful quoting on the command line.

Using resource names follows the existing sharemgr syntax of: sharemgr set-share -s path -r resource group

When the SMB protocol is enabled on a group, resource names MUST be supplied. This is a requirement of the SMB protocol. Additional names are added using the same syntax as adding the original share and resource. Removing resource names uses the remove-share subcommand syntax: "sharemgr remove-share -s path -r resource group". If multiple resources exist, then just the specified resource is removed. If there is only one resource defined, then the resource and share will be removed.  If remove-share is used without the "-r resource" option, then all resources and the share will be removed.

To illustrate, the following example will create a group "homegroup" with default protocols of nfs and smb. Then a share will be added followed by adding a second resource to the share.

    $ sharemgr create homegroup
    $ sharemgr add-share -s /export/home -r home homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()

    $ sharemgr add-share -s /export/home -r maison homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()

The above would result in /export/home being shared by NFS and "home" and "maison" being shared via SMB. If maison should be in a different Active Directory Container, this can be done by setting the "ad-container" property on the maison resource. 

    $ sharemgr set -P smb -p ad-container=cn=Other -r maison -s /export/home homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()
                   maison=/export/home   smb=(ad-container=cn=Other)

Because resource names are full objects, it is possible to place SMB properties at any of the three levels: group, share and resource with resources inheriting as appropriate just as it does with group and share for NFS.

Renaming a resource is implemented with the set-share sub-command. To rename the resource "maison" to "chateau", use sharemgr set-share -r maison=chateau -s /export/home homegroup

Resource names are global to all groups and must be unique.

If you want to add the SMB protocol to an existing group, it can be done with "sharemgr create -P smb group" command. This assumes that a resource name has been added to each existing share.  If you want to enable SMB but not go through the process of adding a resource name to each share, sharemgr will do it for you if you use the "-f" option.  E.g. "sharemgr create -P smb -f group" will enable SMB after adding a constructed resource name to each share.  The constructed resource name will be based on the path of the share with all the disallowed characters (/) being replaced with underscore (_). This will get things running and allows you to rename the resources later.




Sunday Nov 04, 2007

Sharemgr gets a new protocol

With the introduction of SMB (aka CIFS) server support to Solaris, sharemgr has been enhanced to fully support it. The SMB server implements Windows file sharing functionality. While some of the new features have been discussed in earlier blog entries, there are a few new features as well as details on how the SMB functionality is mapped into sharemgr that will be covered in more detail. The new features include:

  • new protocol "smb"
  • a group may have either, or both, of "nfs" and "smb" enabled
  • a share may have multiple resource names
  • resource names are case insensitive for all protocols
  • resources may be renamed
  • resource names may be used to identify shares on the command line
  • resources may have protocol specific properties for protocols that support this concept
  • sharectl supports SMB operational properties

In general, sharemgr behaves for SMB the same as it does for NFS.  The NFS functionality hasn't been changed other than the resource names can be used as an alias for the path. A given share group may have either or both "nfs" and "smb" enabled. When SMB is enabled, there may be some things that are required for NFS that weren't when only NFS was enabled.

Subsequent blog entries will discuss the SMB support in more detail. Others bloggers will be covering the SMB functionality in more detail.




« July 2016