Well, we have a bit of experience with kCIFS as well - mostly it
has worked well for us, on a deployment with MSAD; we had a lot
more trickery with NFSv4-style ACLs to have both local work on
the storage server, NFS usage and CIFS usage somewhat consistent.
User mapping from MSAD into locally defined accounts also worked
acceptably well for us... Almost. I don't quite remember specific
details (can dig if required, or not - if the rough description
rings a bell already), but some ways of access to the
One big problem was (and AFAIK remains) that the directory entries
(or their ACLs?) often become bound to some entities known only
to the storage server's global zone (I can't tell off the top of
my head whether this was about ephemeral IDs, or just ZFS ACLs
mentioning accounts and groups defined only in the GZ).
While these files and directories are accessible okay in the
GZ and, for the most part, in that server's local zones which
lofs-mount filesystems from the GZ, access over NFS fails with
some bad ACL error; woe be to home dirs accessed and tainted
by CIFS - they might no longer be accessible to UNIX systems
until reset to POSIX-only ACLs or ACLs with well-known groups.
Otherwise it just complicates management of common file archives
in shared workspaces, if files are later accessed from UNIX too,
and that - rarely (since most active users were added into idmap
mappings explicitly, to back up wildcard ruled).
Maybe this would work if ALL systems and local zones were MSAD
integrated clients as well, but they are not.
Actually, here is an example; I am not sure I can quickly conjure
up more:
=== View from the GZ
# ls -ladV /export/home/jim/public_html/SSR-20090329.FLV
-r--r--r--+ 1 jim staff 169942464 Mar 31 2009
/export/home/jim/public_html/SSR-20090329.FLV
user:jim:-wxp----------:-------:deny
user:jim:rwxpdDaARWcCos:-------:allow
group:2147483648:-wxp----------:-------:deny
group:2147483648:rwxpdDaARWcCos:-------:allow
owner@:-wxp----------:-------:deny
owner@:r------A-W-Co-:-------:allow
group@:-wxp----------:-------:deny
group@:r-------------:-------:allow
everyone@:-wxp---A-W-Co-:-------:deny
everyone@:r-----a-R-c--s:-------:allow
# idmap dump | grep 2147483648
(nothing)
=== View over loop-mount in a local zone on the storage server
$ ls -ladV /export/home/jim/public_html/SSR-20090329.FLV
-r--r--r--+ 1 jim nobody 169942464 Mar 31 2009
/export/home/jim/public_html/SSR-20090329.FLV
user:jim:-wxp----------:-------:deny
user:jim:rwxpdDaARWcCos:-------:allow
group:nobody:-wxp----------:-------:deny
group:nobody:rwxpdDaARWcCos:-------:allow
owner@:-wxp----------:-------:deny
owner@:r------A-W-Co-:-------:allow
group@:-wxp----------:-------:deny
group@:r-------------:-------:allow
everyone@:-wxp---A-W-Co-:-------:deny
everyone@:r-----a-R-c--s:-------:allow
(mostly the same - except that the strange group was mapped into "nobody")
=== View from same local zone over NFS:
$ ls -laV /net/storage/export/home/jim/public_html/SSR-20090329.FLV
ls: can't read ACL on
/net/storage/export/home/jim/public_html/SSR-20090329.FLV: Not owner
$ ls -la /net/storage/export/home/jim/public_html
ls: can't read ACL on
/net/storage/export/home/jim/public_html/SSR-20090329.FLV: Not owner
total 4211
-r--r--r-- 0 root root 169942464 Jan 1 1970
drwxr-xr-x+ 8 jim staff 19 Apr 27 18:42 .
...
In the second case the directory entry pops up - with proper file
size, but no date or link-count.
===============
Again, maybe it works differently for others; maybe the problem was
fixed in the past few years (that storage box is OpenSolaris SXCE)...
This did not annoy us enough to abandon kernel CIFS which "just worked"
for that project and remains "acceptable with known quirks". A bigger
problem was the lack of CIFS child-mounts, which I think Nexenta had
solved at some time (BTW, is it integrated in common illumos-gate?)
What I meant to say is that, possibly, "tight integration" of ZFS and
kCIFS is not always good - i.e. if it leads to such show-breaking ACLs
to be stored in the ZFS filesystems... I have no idea if Samba, even
with ACL support (there is some, right?) can cause similar breaks...
My 2c,
//Jim
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
