[illumos-Developer] RFE 604: Proposal to allow CIFS server to traverse mount points

[taemun]

I'm also supportive of this idea. That this wasn't default functionality in
OpenSolaris when I first started using it was a bit of a shock - and meant I
ended up using Samba (which has some issues of its own).

I'm not sure if it was covered and I'm just blind, but I would also like to
see the ability to mount /tank/ to \\server\tank, but also /tank2/backups to
\\server\tank\backups. So, not just child datasets, but other ones.

Cheers,

On 15 January 2011 09:29, Aram Hăvărneanu <aram.h at mgk.ro> wrote:

> 0.  Problem: CIFS shares do not export everything under the root of the
> share, which is what CIFS users expect.
>
> Background: CIFS servers and NFS servers implement somewhat different
> ideas about what is a "share" and what it means to "share" something.
>
> In NFS, shares (exports) are essentially a property of some directory,
> and the server's path name to that directory is the share name.  In most
> NFS servers, a directory can only be exported by its pathname, and
> exporting directories below an already exported directory is either not
> allowed or requires some special handling.  In CIFS, shares have names
> independent of the directory exported (or "resource", i.e. printer,
> device). Multiple shares may export the same directory, possibly with
> different features (access, etc.).  Shares may export multiple levels of
> the directory hierarchy (and often do), i.e. both the root of the
> filesystem and subdirectories may be shared.
>
> The OpenSolaris CIFS implementation was designed to closely match NFS
> sharing semantics, and to present a consistent administrative model
> between NFS and CIFS.  Those are good goals, but the degree to which
> CIFS was made to work "just like NFS" has left CIFS users confused and
> disappointed. Probably the most common complaint goes something like:
> "It's great how I can use ZFS to create lots of filesystems, each with
> its own snapshots and quotas, etc. but when I share my filesystems for
> CIFS, none of the "child" ZFS filesystems can be seen by my clients.
> Why not?"
>
> This memo proposes modifying the behavior of ZFS "child" filesystems
> that exist below some CIFS share.  There are some options in how this
> might be done, and some of those are presented for discussion, along
> with recommendations.
>
> 1.  In the current implementation, the in-kernel CIFS server
> has the following behavior:
>
>    1.  There is a 1:1 relation between the share and exported
>    filesystems. When connecting, a client sees a separate share for
>    each exported filesystem, irrespective of the server side namespace
>    relation between exported filesystems thus creating a flat namespace
>    on the client side.
>
>    2.  While ZFS encourages a nested filesystem model, these
>    nested filesystems are allowed to have properties different from
>    their parents.  This presents problems for exporting everything
>    under some directory to CIFS clients because CIFS clients expect
>    properties like "case insensitive search" to be uniform throughout
>    the share.  Clients request these properties for shares they connect
>    to, and the server's answer constitutes a "promise" to the client
>    about what semantics can be expected.  The server could cause
>    client-side applications to break if it were to break that promise.
>
>    3.  Server side objects that are not exported to clients,
>    such as mount point directories act as invisible files. Clients
>    can't see them, but if they try to create files with that names, the
>    create will fail mysteriously.
>
> 2.  With this design, we would allow the CIFS server to
> traverse from the share's root filesystem to a child filesystem provided
> the child filesystem supports the features we guarantee to the client that
> the share supports. It does this by checking that the target filesystem
> has the same set of relevant features as the share's root filesystem.
> This set of features would be:
>
>    1.  case-(in)sensitivity: the child file system should be in
>    the same name lookup mode (from a case sensitive point of view)
>    as the share's root filesystem.
>
>    2.  ACL support: the child file system should support the same
>    type of ACLs as the share's root fileystem (if any).
>
> With this design we would also implicitly solve 1.3.  There are no more
> invisible and inaccessible files.  Server side symlinks are followed as
> long as they are expressed relative to the share's root and they point
> to a compatible filesystem. Absolute symlinks or symlinks that point
> outside of the tree continue not to work and maintain their status of
> inaccessible files.
>
> With this proposal, there will not be any case where data was previously
> shared and now it is not.  This change would causes the server to share
> a strict superset of what was previously shared, so administrators
> should not worry about some files not being shared anymore.
>
> 3.  With this proposal we do not look whether the target filesystem is
> shared explicitly or not.  For example is previously you had the
> following filesystem hierarchy:
>    /a
>    /a/1
>    /a/2
>    /a/not-shared
>    /a/not-shared/1
>
> where /a, /a/1, /a/2 have the sharesmb property set and /a/not-shared
> and /a/not-shared/1 do not.  Previously, a share for /a, /a/1 and /a/2
> will have been created and /a/not-shared and /a/not-shared/1 would be
> inaccessible on the client side.  With the proposed change, only a share
> for /a, /a/1, and /a/2 will be created, just like it was the case
> before, however you will be able to access /a/not-shared* (provided file
> permissions allow this) from the client side by connecting to /a and
> traversing the filesystem from there.  This is consistent with what both
> the Microsoft SMB server and Samba do.  However, because the smbsrv
> property is inheritable and because a child filesystem has that property
> unset, it means that an administrator explicitly reset that property, so
> it might be interpreted that he wanted that filesystem NOT to be shared
> in any way.
>
> In Windows, with the Microsoft SMB server, shares are just convenient
> names for export points.  After connecting to an SMB share, the
> Microsoft SMB server does not restrict access to the subset of files
> that reside within the share's root filesystem on the server side.
>
> This memo proposes changing the meaning of the sharesmb property in
> order to align to what Microsoft SMB server does.  At the moment it is a
> switch to enable or disable exporting namespaces over wire.  With this
> change it would only mean that an explicit share is created for that
> filesystem and nothing more.  Setting sharesmb=no underneath another
> shared directory would no longer prevent access below that point.  It
> would only cause the system to not create _another_ share at that
> directory.
>
> 4.  It is open to debate whether this change in meaning is acceptable or
> not.  Is it important that we check whether a child file system is
> explicitly shared (as with the current behavior) or can we just share
> everything underneath (as Microsoft SMB server does)?
>
> 5.  Assuming people are OK with the changed semantics of the sharesmb
> property, it might be appropriate to also consider chaning the
> inheritance rules for this property.  Rather than inherit from it's
> parent dataset, perhaps a default of sharesmb=no would be better?
>
> Signed by: Aram Hăvărneanu, Gordon Ross, Garrett D'Amore
>
> --
> Aram Hăvărneanu
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.illumos.org/pipermail/developer/attachments/20110115/4f6809af/attachment.html>