Created attachment 16113 [details]
Patch for 4.11 backported from master

Created attachment 16114 [details]
Patch for 4.12 cherry-picked from master

There're will be a few more fixes, see
https://gitlab.com/samba-team/samba/-/merge_requests/1447

I also found that the
smb2.durable-v2-delay.durable_v2_reconnect_delay_msec triggers this
(at least in master).

There's seems to be a bug in share_mode_cleanup_disconnected(),
        data->have_share_modes = false;
        data->modified = true;
is not enough to delete the record in master.

The following naive patch to seems to fix it for
smb2.durable-v2-delay.durable_v2_reconnect_delay_msec:

diff --git a/source3/locking/share_mode_lock.c b/source3/locking/share_mode_lock.c
index a93141304b26..fceb09f7f2d3 100644
--- a/source3/locking/share_mode_lock.c
+++ b/source3/locking/share_mode_lock.c
@@ -664,9 +664,16 @@ static NTSTATUS share_mode_data_store(struct share_mode_data *d)
 
        d->sequence_number += 1;
 
-       status = locking_tdb_data_fetch(key, d, &ltdb);
-       if (!NT_STATUS_IS_OK(status)) {
-               return status;
+       if (d->have_share_modes) {
+               status = locking_tdb_data_fetch(key, d, &ltdb);
+               if (!NT_STATUS_IS_OK(status)) {
+                       return status;
+               }
+       } else {
+               ltdb = talloc_zero(d, struct locking_tdb_data);
+               if (ltdb == NULL) {
+                       return NT_STATUS_NO_MEMORY;
+               }
        }
 
        if (ltdb->num_share_entries != 0) {

But I'm not sure it's correct.

Dammit, I think I found this a couple of weeks ago when writing the test for async disconnect but didn't track it down to this issue. My "force disconnect" test ended up leaving a dead record in locking.tdb which I never tracked down fully (I cheated by moving the force-disconnect after the one that was complaining about the dead record). Sorry.

(In reply to Stefan Metzmacher from comment #3)
> But I'm not sure it's correct.

During a phone call Stefan, Ralph and I agreed that it would be easier to understand if share_mode_cleanup_disconnected() walked the share mode entries again using share_mode_forall_entries(), setting all disconnected entries to stale. share_mode_forall_entries() would then take care of removing the locking.tdb record. For durable file handles this is no performance penalty, as there will only ever be one of those, and even for a later implementation of persistent file handles this should not cause trouble as this is an asynchronous process independent of normal smbd operations.

Created attachment 16141 [details]
Patches for v4-12-test

Created attachment 16144 [details]
Patches for v4-11-test

Reassigning to Karolin for inclusion in 4.11 and 4.12.

(In reply to Ralph Böhme from comment #8)
Pushed to autobuild-v4-{12,11}-test.

(In reply to Karolin Seeger from comment #9)
Pushed to both branches.
Closing out bug report.

Thanks!

One origin that triggered this bug, is a regression in 4.13.

In 4.13 share_mode_cleanup_disconnected() doesn't delete the
locking.tdb entry.

Created attachment 16190 [details]
Patches for v4-13-test

(In reply to Stefan Metzmacher from comment #12)
Pushed to autobuild-v4-13-test.

this bug was referenced in commit df1ff55deb92827eb502c1857a0039743752c6b3 in the samba v4-13-test branch

This bug was referenced in samba v4-13-test commit 4aa4f12f5333bd4913989ae1f54027e480535eb4

This bug was referenced in samba v4-13-test commit 0a682a1898695839fe4933af61c8a1d4068005a3

This bug was referenced in samba v4-13-test commit 431192896a2e31487dcd5155e35ac333bb4dd472

This bug was referenced in samba v4-13-test commit df1ff55deb92827eb502c1857a0039743752c6b3

This bug was referenced in samba v4-13-test commit b83efaec1981600668fae5f67a483c2c698b6e68

This bug was referenced in samba v4-13-stable:

431192896a2e31487dcd5155e35ac333bb4dd472
e62a37e9748839f8f474b5a28c607f6630b66c71
4aa4f12f5333bd4913989ae1f54027e480535eb4
8a8b90eba76b94f3d7291ccc86fe1e80d4423ff3
b83efaec1981600668fae5f67a483c2c698b6e68
0a682a1898695839fe4933af61c8a1d4068005a3
df1ff55deb92827eb502c1857a0039743752c6b3