On 15/04/2020 16:57, Ralph Boehme via samba wrote:> Am 4/15/20 um 10:59 AM schrieb Giuseppe Lo Presti via samba: >> So the question is do you acknowledge the correct behaviour should be to >> prevent the second client from getting the lock? > > yes. My bet: your cluster filesystem device nummer differs across nodes. Cf:Bingo! Indeed inodes are (obviously) identical, but device numbers differ. For the record, the solution has been to include as suggested: vfs objects = fileid fileid:algorithm = fsname in the global configuration. With this, Microsoft Office - the real use case - works correctly by detecting files opened by other users, no matter which gateway users hit. So thanks a lot, case solved. And what would be your advice concerning the other locking settings? In particular: posix locking = no strict locking = no oplocks = no level2 oplocks = no kernel oplocks = no Thanks again, Cheers, Giuseppe
Am 4/16/20 um 10:42 AM schrieb Giuseppe Lo Presti:> Bingo! > > Indeed inodes are (obviously) identical, but device numbers differ. For > the record, the solution has been to include as suggested: > > ? vfs objects = fileid > ? fileid:algorithm = fsname > > in the global configuration. With this, Microsoft Office - the real use > case - works correctly by detecting files opened by other users, no > matter which gateway users hit. > > So thanks a lot, case solved. And what would be your advice concerning > the other locking settings? In particular: > > ? posix locking = no > ? strict locking = no > ? oplocks = no > ? level2 oplocks = no > ? kernel oplocks = nothat depends on your use case. If you sharing SMB only there's probably no need to enable posix locking or kernel oplcks, but you should not change the other options from their default values unless you know what your're doing. -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20200416/e49d8019/signature.sig>
On 16/04/2020 11:12, Ralph Boehme via samba wrote:> Am 4/16/20 um 10:42 AM schrieb Giuseppe Lo Presti:[...]>> the other locking settings? In particular: >> >> ? posix locking = no >> ? strict locking = no >> ? oplocks = no >> ? level2 oplocks = no >> ? kernel oplocks = no > > that depends on your use case. If you sharing SMB only there's probably > no need to enable posix locking or kernel oplcks, but you should not > change the other options from their default values unless you know what > your're doing.Actually the filesystem is also shared via FUSE mounts on Linux clients. My understanding so far was that posix and strict locking set to yes would cause an unnecessary performance impact, whereas other options were tried in the context of this troubleshooting. Will revert them to their default. And to close on this thread, I'd suggest to document the vfs objects parameter in the CTDB documentation, as it's a pretty unintuitive one to find out when configuring a samba cluster. Thanks a lot, Cheers, Giuseppe