> it may make sense to build others which you really use on every > machine statically to not need to add them in your smb.confThat's what I expected, too. Since then I made some experiences. I built samba 4.3.6 with a static vfs_acl_xattr module. It is builtin alright, it is listed under "Builtin modules" at the output of "smbd -b". Then: -- Comment"vfs objects = acl_xattr" from a share in smb.conf -- Restart all Samba services -- From Windows, create a folder "newfolder" in that same share -- Run "getfattr -n security.NTACL newfolder". getfattr outputs "security.NTACL: No such attribute" -- delete folder "newfolder" -- In smb.conf, remove comment from "vfs objects = acl_xattr" under the same share -- Restart all Samba services -- From Windows, create a folder "newfolder" in that same share -- Run "getfattr -n security.NTACL folder". getfattr finds the extended attribute and presents it correctly. So, it looks like our expectations about this didn't come to fruition. Shouldn't the builtin module do its job normally?
Am 15.03.2016 um 21:07 schrieb Miguel Medalha:> >> it may make sense to build others which you really use on every >> machine statically to not need to add them in your smb.conf > > That's what I expected, too. Since then I made some experiences. I built > samba 4.3.6 with a static vfs_acl_xattr module. It is builtin alright, > it is listed under "Builtin modules" at the output of "smbd -b". > > Then: > -- Comment"vfs objects = acl_xattr" from a share in smb.conf > -- Restart all Samba services > -- From Windows, create a folder "newfolder" in that same share > -- Run "getfattr -n security.NTACL newfolder". getfattr outputs > "security.NTACL: No such attribute" > -- delete folder "newfolder" > -- In smb.conf, remove comment from "vfs objects = acl_xattr" under the > same share > -- Restart all Samba services > -- From Windows, create a folder "newfolder" in that same share > -- Run "getfattr -n security.NTACL folder". getfattr finds the extended > attribute and presents it correctly. > > So, it looks like our expectations about this didn't come to fruition. > Shouldn't the builtin module do its job normally?well, not sure - in fact you can configure each share with different "vfs objects" and so configuration likely still is needed - i referred more to my expierience with httpd where you don't need "LoadModule" lines for static compiled modules at the end i would say it's not worth at all to spend time with that micro-optimization if there is any optimization at all and stick with defaults -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160315/55976b50/signature.sig>
> well, not sure - in fact you can configure each share with different > "vfs objects" and so configuration likely still is needed - i referred > more to my expierience with httpd where you don't need "LoadModule" > lines for static compiled modulesThere has been a change in the configuration/behavior of modules and their stacking and that change is not well documented. In previous versions of Samba that exact same acl_xattr module could be declared in the [global] section of smb.conf and it would apply to ALL the shares, as should be expected. I still have here a retired samba 3.2 server and it behaves in that way. This can be very practical if all your clients are Windows workstations, as is often the case. As a matter of fact, there was a general principle, even referred to in the Samba documentation, that global "G" parameters could be used only globally but share "S" parameters could be used both in shares and globally, in which case they would apply to all shares. This was very practical but seems to no longer be the case for Samba 4.x.> at the end i would say it's not worth at all to spend time with that > micro-optimization if there is any optimization at all and stick with > defaultsIt is worth spending that time in the sense that we can learn about the behavior of the software we rely on.