Wednesday Feb 18, 2009

ACLs on Shares

With build 109 of Open Solaris, a new feature has been added to the CIFS server - ACLs on Shares.

ACLs on shares bring better compability with the Microsoft implementation and allow more control over access than the CIFS server previously supported.  Basically, it is now possible to set and modify ACLs on the individual share resources for CIFS.  That is, if you create a CIFS resource called "My Files" on a ZFS dataset pool/my-files, you can add another layer of ACL support at the share level.  This is done using standard Open Solaris utilities (chmod to modify and ls to view).  There is now a new file system object that holds the ACLs for ZFS file systems.  In the case of "My Files", the root of the file system is /pool/my-files. If you "cd /pool/my-files/.zfs/shares", you will now see a file object with the name "my_files".

This file object is only used to hold the ACL values for the share. It cannot be renamed or removed using file system utilities.  Only chmod and ls (or other utilities that deal with ZFS ACLs) work on it.

If you create a second resource (CIFS share) on the same path, that share name will also appear in the same directory.  Each one of these objects may have different ACL specifications. The result is that you could have one share that is read/write while the other is read-only.

ACLs on shares are essentially used to remove access that the file system may be providing.  When used in conjunction with the host-based access control, there is a great deal of fine level control over access available.

Most of the time there won't be a need for ACLs on the individual shares, but they do provide some flexibility that can be useful. One possibility is to provide a standard, read-only share for a path that is the one normally available. A second share defined for the same path could have read-write set for some users in order for them to do maintenance on the share.

 Combined with the ACLs on the underlying file system and the coarser level, host-based access control (the rw/ro/none properties on a resource), access can be controlled with quite a bit of detail.  One warning is that with this much control, it is also possible to setup shares that you cannot access, so be careful and plan things out carefully.

Thursday Oct 30, 2008

Some new features

A new set of features have been recently added to sharemgr (ON build 103). These have been long pending RFEs for both NFS and SMB.

New properties available for NFS:

  • none=<access-list>
    Any host that is attempting access that is found in the access-list will be denied all access.

  • root_mapping=uid
    Any root user that is allowed access via the root=<access-list> property will have the root UID mapped to uid on the server

  • charset=<access-list>
    Any host found in the access-list will be assumed to be using the specified charset and file names and paths will be converted between charset and UTF8 on the server.

New properties available for SMB:

  • none=<access-list>
    Any host that is attempting access that is found in the access-list will be denied all access.

  • ro=<access-list>
    Any host found in the access-list will have read-only access

  • rw=<access-list>
    Any host found in the access-list will have read-write access

Note that the new SMB properties are the same as those of the same name in NFS.  Details of all the properties will be included in the sharemgr man page. Adding these properties to SMB and NFS provides functionality that is present in the StorEdge 5210/5310 products.

Note that the <access-list> is the same as has been part of NFS for a long time. It is a list of hosts and/or netgroups. The sharemgr(1m) man page and share_nfs(1) man page describe them in detail.

Monday Dec 17, 2007

sharemgr screencast available

I have just completed a screencast giving an overview of sharemgr usage with examples.  The examples cover NFS and SMB as well as managing with sharemgr directly or via ZFS.  The screencast can be found at

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.




« June 2016