Created attachment 17406 [details] SambaFailAndWindowsWorkPackets Configuration: QNAP TVS-h1288X (QuTS hero) Firmware: h5.0.0.1892 smbd (samba daemon) Version 4.13.14 Steps to Reproduce: Note: some of these steps are not relevant but are more describing what this particular unit test is doing. 1. First SMB Client logs into the server 2. Second SMB Client logs into the server 3. First client Creates test dirs and test file of PR_blah/PT_0000000000/testfile and writes initial data into the file. A Read/Write/Handle lease is requested and granted. 4. First client verifies it can exclusive lock bytes 0-9 5. First client verifies it can exclusive lock bytes 53-62 6. First client verifies it can read bytes 0-125 7. First client verifies that attempt to lock 4-6 correctly fails as that range is already locked 8. First client verifies that attempt to unlock 5-9 correctly fails as that does not match a previous lock 9. Second client opens the same file and gets granted a H lease 10. Second client verifies it can exclusively lock bytes 10-19 11. Second client tries to read bytes 0-4 Expected Results: Read should fail with STATUS_LOCK_CONFLICT because First client is holding exclusive lock on bytes 0-9 Actual Results: Samba server allows the read to occur with no error. This is wrong according to [MS-SMB2] 2.2.26.1 which says that exclusive locks do not allow other opens to read/write or lock within the range. I have attached a packet trace showing the incorrect behavior from Samba (Read attempt at 221) and the correct behavior from Windows (Read attempt at 228).
What is the setting of "strict locking" in the smb.conf ? ---------------------------------------------------------------------- strict locking (S) This is an enumerated type that controls the handling of file locking in the server. When this is set to yes, the server will check every read and write access for file locks, and deny access if locks exist. This can be slow on some systems. When strict locking is set to Auto (the default), the server performs file lock checks only on non-oplocked files. As most Windows redirectors perform file locking checks locally on oplocked files this is a good trade off for improved performance. When strict locking is disabled, the server performs file lock checks only when the client explicitly asks for them. Well-behaved clients always ask for lock checks when it is important. So in the vast majority of cases, strict locking = Auto or strict locking = no is acceptable. Default: strict locking = Auto
If you can reproduce with "strict locking = yes" then I'll agree it's a bug :-).
Here's the code for "strict locking = Auto". Note that this *should* check locks if the client only has a handle lease as the optimization won't kick in then. Of course, general locking ("locking = yes") has to be turned on also. if (!lp_locking(fsp->conn->params) || !strict_locking) { return True; } if (strict_locking == Auto) { uint32_t lease_type = fsp_lease_type(fsp); if ((lease_type & SMB2_LEASE_READ) && (plock->lock_type == READ_LOCK)) { DBG_DEBUG("optimisation - read lease on file %s\n", fsp_str_dbg(fsp)); return true; } if ((lease_type & SMB2_LEASE_WRITE) && (plock->lock_type == WRITE_LOCK)) { DBG_DEBUG("optimisation - write lease on file %s\n", fsp_str_dbg(fsp)); return true; } } br_lck = brl_get_locks_readonly(fsp); if (!br_lck) { return true; } ret = brl_locktest(br_lck, plock);
(In reply to Jeremy Allison from comment #3) When the "bug" occurs, smb.conf is showing locking = yes and no entry found for "strict locking"
Created attachment 17409 [details] StrictLockFailureLogPackets
(In reply to Jeremy Allison from comment #2) Still fails. Attach smbd logs and matching packet trace.
(In reply to suinn from comment #5) Can you just confirm this trace is with "strict locking = yes" set in smb.conf ? Thanks !
(In reply to Jeremy Allison from comment #7) Yes, strict locking was enabled.
(In reply to suinn from comment #8) Strange things are being seen in the log and not in the trace. Looking at the debug level 10 log inside https://bugzilla.samba.org/attachment.cgi?id=17409 I see (showing line numbers): 49184 smbd_smb2_request_dispatch: opcode[SMB2_OP_LOCK] mid = 173 ... 49242 smbd_smb2_lock_send: PR_62C4C762_0000B862/PT_0000000000/testfile - fnum 2598490438 ... 49244 smbd_smb2_lock_send: index 0 offset=4, count=3, smblctx = 2927911448 type 1 ... 49266 brl_get_locks: 2 current locks on file_id 27:143396:0 ... 49268 print_lock_struct: [0]: smblctx = 2927911448, tid = 3193009125, pid = 9389, start = 0, size = 10, fnum = 2598490438, WRITE WINDOWS_LOCK ... 49270 print_lock_struct: [1]: smblctx = 2927911448, tid = 3193009125, pid = 9389, start = 53, size = 10, fnum = 2598490438, WRITE WINDOWS_LOCK ... 49292 smbd_smb2_request_done_ex: mid [173] idx[1] status[NT_STATUS_LOCK_NOT_GRANTED] body[8] dyn[yes:1] at ../../source3/smbd/smb2_server.c:3923 This doesn't match either the packet trace (mid=173 is packet 191 which shows SMB2_LOCK offset=0,size=10 as you describe), or the textural description of what you say your client is doing. Can you clean out the logs, restart the QNAP box and send me a clean packet trace + log.smbd of it going wrong please ?
Created attachment 17437 [details] Samba logs and packet capture again. /etc/config/smb.conf shows strict locking = yes locking = yes