Claudia Hildebrandt wrote:
> You've created two zfs filesystems outer and inner.
> # zfs create -o casesensitivity=insensitive tank/outer
> # zfs create -o casesensitivity=insensitive tank/outer/inner
>
> inner is defined as a zfs filesystem, it is not just a simple directory in
> outer, it is a filesystem and it is a ZFS file system hierarchy.
Yes, I am already aware of that. I am also aware that the new "inner"
filesystem inherits its defaults from its parent (outer), so that by
default it ends up mounted in a self-named subdirectory of the root
directory of the "outer" filesystem.
> If you'd set a mountpoint, for instance:
> # zfs set mountpoint=/export/home tank/outer
> it would be inherited by the child.
>
> Then you shared outer, but not inner.
>
> # zfs sharesmb=name=outer tank/outer
> # zfs sharesmb=off tank/outer/inner
>
> So inner is not a share and therefor not accessible.
This does not follow unless you use a particularly selective meaning for
the word "share" in this context.
There are at least two meanings:
* "a share": a named point on the server from which a subtree of the
server's file system is exposed to clients
* "shared": a given filesystem on the server is accessible to clients,
whether directly by a name, or indirectly via a mount point
I am interested in the first definition as it applies to the parent
directory of inner's mountpoint. For this purpose, the fact that the
"inner" filesystem is not "a share" is irrelevant; it should be "shared"
by virtue of being mounted in a subdirectory of the "outer" filesystem,
which is itself "a share".
> As far as I know, a file system with sharesmb property set to "off" can be
> managed through share(1M), unshare(1M), and dfstab(4).
This system seems to be obsolete. sharemgr(1m) appears to be the
favoured command, as evidenced in the comment in /etc/dfs/dfstab:
# Do not modify this file directly.
# Use the sharemgr(1m) command for all share management
# This file is reconstructed and only maintained for backward
# compatibility. Configuration lines could be lost.
And the NOTES section of the manpage:
NOTES
Do not modify this file directly. This file is reconstructed
and only maintained for backwards compatibility. Configura-
tion lines could be lost.
Use the sharemgr(1M) command for all share management.
> If the property is set to "on" it is automatically shared or unshared with
> zfs share and zfs unshare commands.
> And finally, if you change the property sharesmb the share and all children
> inheriting the property are reshared, except that ones that are set to "off".
> So the filesystem inner is not a share !
Perhaps it would be easier to get what I'm after if I explained my
desired end result:
* Two zfs filesystems ("inner" and "outer") so that I can specify
different properties for each
* One ("inner") a descendant of the other ("outer") so that properties
will be inherited
* One ("inner") mounted inside the other ("outer") in a directory called
"inner"
* Available via CIFS protocol via a single share name on the server,
"outer"
* Whereby '\\<server-name>\outer\inner' is a valid UNC pathname from
client Windows machines
How can I do this using the cifs/zfs integration?
# ************************************************************
As far as I can figure it, it is not possible using
OpenSolaris+zfs+cifs.
Here is another approach I tried, being more explicit about the
mountpoints:
# mkdir /export/outer
# zfs create -o casesensitivity=insensitive tank/outer
# zfs set mountpoint=/export/outer tank/outer
# mkdir /export/outer/inner
# zfs create -o casesensitivity=insensitive tank/outer/inner
# zfs set mountpoint=/export/outer/inner tank/outer/inner
# zfs sharesmb=name=outer tank/outer
# zfs sharesmb=off tank/outer/inner
# /bin/chown -R barrkel:staff /export/outer/
# /bin/chmod -R A=everyone@:full_set:fd:allow /export/outer/
# /bin/ls -vR /export/outer/
/export/outer/:
total 4
drwxrwxrwx+ 2 barrkel staff 2 Mar 16 13:29 inner
0:everyone@:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/delete_child/read_attributes/write_attributes/delete/read_acl
/write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
/export/outer/inner:
total 0
This didn't work, it had the same inaccessible problem as my original
post.
I deleted the share via zfs, and recreated it via sharemgr instead, in
case it was zfs's meddling that was causing issues:
# zfs sharesmb=off tank/outer
# sharemgr add-share -r outer -s /export/outer/ cifs
# sharemgr show -v
cifs
outer=/export/outer
(IIRC, 'cifs' is a share group I created earlier that uses smbfs
protocol:
# sharemgr create -P smb cifs
)
This also didn't work.
-- Barry
--
http://barrkel.blogspot.com/
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
