3.2.7 vs 3.5 locking logic/mechanism - locking denied to non-owners

[lejeczek]

thanks Volker for your reply
nope, has no effect

and in log as before:

2012/04/27 11:16:00.597601, 10] 
locking/locking.c:926(fetch_share_mode_unlocked)
   fetch_share_mode_unlocked: no share_mode record around 
(file not open)

and as before suffices, for 3.5.4-68.el6, to change 
ownership to be of the accessing user and

locking/locking.c:552(parse_share_modes)
   parse_share_modes: delete_on_close: 0, owrt: Mon 30 May 
2011 12:45:56 AM BST BST, cwrt: Thu 01 Jan 1970 01:00:00 AM 
BST BST, tok: 0, num_share_modes: 1
[2012/04/27 11:19:32.098836, 10] 
locking/locking.c:655(parse_share_modes

it works, that is weir, no?
but unfortunately it's not exactly the solution for me, 
changing the owner every time...


On 27/04/12 10:21, Volker Lendecke wrote:
> On Fri, Apr 27, 2012 at 10:01:34AM +0100, lejeczek wrote:
>> what I'd like to have working OK is that client accessing a 3.5
>> read-only share like 3.2.7 does, regardless of permissions, meaning
>> not needing to be the owner (which sort of makes no sense since it's
>> read only, right?)
> If it's guaranteed to be a read only share, you might want
> to try "share modes = no". Be aware that this severely
> breaks SMB semantics, but at least with a read only share
> you won't corrupt your data.
>
> Volker
>