Created attachment 17405 [details] Packet traces showing Samba Failure and Windows Server working Configuration: QNAP TVS-h1288X (QuTS hero) Firmware: h5.0.0.1892 smbd (samba daemon) Version 4.13.14 Steps to Reproduce: 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. Second client attempts to open the same file 5. Lease Break Notification is sent by server changing lease from RWH to Read/Handle 6. Second client opens test file and does read of initial data 7. First Client does a write on the file Expected Results: The write should generate a lease break from RH to none to the second client. Actual Results: Samba server does not send out any lease break to second client. This is incorrect according to [MS-SMB2] 3.3.14 which states that the server must Read caching if data is written to the file. I have attached a packet trace showing the incorrect behavior from Samba (Write attempt at 202) and the correct behavior from Windows (Write attempt at 206).
Can you upload a debug level 10 log from the smbd processes as well ? We should see a debug message from contend_level2_oplocks_begin_default() in the smbd that receives the write that looks like: DEBUG(10, ("Breaking through lease key %"PRIu64"/%"PRIu64"\n", state.lease_key.data[0], state.lease_key.data[1]));
Created attachment 17408 [details] smbdDebugLogAndPackets
(In reply to suinn from comment #2) Yeah, same problem. log.smbd doesn't match the packet traces :-(.
Created attachment 17438 [details] Samba log and packet trace
Created attachment 17439 [details] QNAP script that enables/disables the Samba logging I run it with "samba_log.sh redirect" Run my test, then wait a min or so, then run "samba_log.sh default" Then copy the logs out of Public/log.*
Could this be the same as: https://bugzilla.samba.org/show_bug.cgi?id=15148 Looks like it to me.
(In reply to Jeremy Allison from comment #6) Yes, likely. I have a test and patches almost ready, I'll check the logs here tomorrow and may close my report... This is the wip fix: https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=7bc7eb97157ac6c76307d21ee3e24ea8bbe351e4 within https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master-fileid
(In reply to Stefan Metzmacher from comment #7) This is not the same as bug #15148
(In reply to Stefan Metzmacher from comment #8) This test seems to demonstrate that upstream doesn't have any problem: https://gitlab.com/samba-team/devel/samba/-/commit/1515746ff5469f9f120178a34aed1256b171e915 Here's a pipeline running with it: https://gitlab.com/samba-team/devel/samba/-/pipelines/617051742 I tested in by hand like this: TDB_NO_FSYNC=1 make -j test _FAIL_IMMEDIATELY=1 SOCKET_WRAPPER_KEEP_PCAP=1 TESTS='smb2.lease' The test also applies to v4-13-test and also passes there... Jeremy I mainly based the test on SambaLeaseBreak.pcapng See wireshark st/w/pcap/samba3_smb2_lease_nt4_dc_.pcap after running the above... Jeremy do you see any difference? Would the test (something like): bin/smbtorture //server/share -U'DOMAIN\user' smb2.lease.v2_bug15112 also reproduce it against that server? Currently I'd assume it a QNAP problem...