Hello all, I have a question on PSARC/2009/184 (SMB/CIFS Share Exec Properties) [http://arc.opensolaris.org/caselog/PSARC/2009/184/]
This subject was interesting to me, especially after reading this page by Ed Plese: http://www.edplese.com/samba-with-zfs.html, who suggests snapshots on every connection, per-connection clones for development environments, etc. After reading the maillog of the case, I'm left puzzled with more questions than I had initially. I'd quite appreciate a clarification from authors of the feature, to stay confident that I mixed it all up but the feature is stable and useful ;) First of all, the maillog discussion did not commit to specifying *when* are the map/unmap scripts called. Am I correct to assume that "map" will be called after a successful identification and authentication of a user (it does have Windows name and Unix uid as passable parameters, after all) - and will not be called if the user is not successfully authernticated? One of the usecases suggests creation of Autohome directories upon mapping a specific share. Could someone please elaborate on that phrase? - what is the share to be mapped this way (a generic /export/home lookalike?) - are the individual user homes directories or dedicated personal ZFS datasets (possibly created on the fly upon the first connection)? - is it intended that individual home dirs become SMB shares in their own right (\\server\username) or directories in one common share (\\server\homes\user)? Also, is this mechanism intended for use only with sharectl (as in examples), or with "zfs set sharesmb=..." as well? If yes, is it possible to make it un-inheritable by sub-datasets created some (any) time later (I guess it's more of a zfs question, but I suddenly found myself in the vague about this - perhaps I should've slept more)? While reading the usecase I'm having a brainlock along these lines: *if* the users' homes are dedicated ZFS datasets (perhaps under a common "export/home" zfs dataset), and *if* such datasets can have the "map" property set or inherited to allow for auto-creation of homes and sharing them, then: 1) How do we call the pre-inexistent user's home dir share in the first place? That is, before the home dir is created and shared, there is no share name and no zfs dataset with a sharesmb property, to which we can add this "map" attribute. 2) How do we protect from any typo becoming a new sub-dataset of something? (Theoretical bug. It's biting me, but I don't know even how to formulate it well) Say, the map attribute points to a script which creates homedir ZFS datasets according to a pathname. Then, this map attribute is inherited by each of these homedir datasets, and they in turn become shares with an active exec-map. And then access to any filename potentially triggers this mapping - and so on recursively. Would this be a problem of a script's author/sysadmin (for writing and using such a poor script), or is there some general solution built into the implementation? HTMAS, //Jim -- This message posted from opensolaris.org _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
