>>Wait -- this is supposed to still work, and I have a lot of customers thatdo exactly that.>>"vfs objects" in [global] that applies to all shares then.I just tested it. It works until you put some other vfs module in some share. Then it ceases to work, you have to declare it for all shares. This works: [global] vfs objects = acl_xattr [share] /some/path This does not work: [global] vfs objects = acl_xattr [share] /some/path vfs objects = recycle acl_xattr ceases to work for the share. The only way to make it work is to declare it for all shares: [share] /some/path vfs objects = acl_xattr recycle This behavior only exist since Samba 4.x. All prior versions worked as expected. Although it's not the worst thing in the world, it is nevertheless somewhat of a PITA and violates a general principle that we used to trust and cherish: global (G) parameters work in [global] and share (S) parameters work both in (S) and in (G).
Am 16.03.2016 um 17:43 schrieb Miguel Medalha:> I just tested it. It works until you put some other vfs module in some > share. Then it ceases to work, you have to declare it for all shares. > > This works: > > [global] > vfs objects = acl_xattr > > [share] > /some/path > > This does not work: > [global] > vfs objects = acl_xattr > > [share] > /some/path > vfs objects = recycle > > acl_xattr ceases to work for the share. The only way to make it work is to > declare it for all shares: > > [share] > /some/path > vfs objects = acl_xattr recyclewhat other behavior do you expect? how would you remove "acl_xattr" from global for a share otherwise? global: this is what has to be active everywhere until i say other share: i now say other and i say it *fully* any other behavior in the past by mixing half of [global] and add [share] was as clear bug and undefined behavior -------------- 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/20160316/ca351bfa/signature.sig>
>> what other behavior do you expect? >> how would you remove "acl_xattr" from global for a share otherwise?Well, I wouldn't declare it in [global] then :-)>> global: this is what has to be active everywhere until i say other >> share: i now say other and i say it *fully*>> any other behavior in the past by mixing half of [global] and add [share]was as clear bug and undefined behavior It's a way (maybe a good one) of looking at it. Nevertheless, it worked as I described until version 3.6. I think that you didn't quite understand what I meant. I understand your reasoning but why should declaring an additional module in a share nullify the globally set parameter? Using your terms: global: I want this module to be active for ALL my shares. If I don't want it on all my shares, I won't put it in [global] share: ON TOP of what I already defined globally, I want this module for share A, that module for share B, that other one for share C. This was the previous behavior and it was VERY convenient. Plus, it respected the general principle of "global (G) parameters work in [global] and share (S) parameters work both in (S) and in (G)". This is very clear. The current situation opens a can of casuistic worms, where instead of a simple general principle you will have to specify casuistically where each of the particular parameters work and don't work. AND even if the change is an acceptable one, then it needs to be documented clearly, wouldn't you think?