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