smbd process (crashes and dumps and) disconnects on file delete.

[Christopher R. Hertel]

Before I open a ticket...

Has anyone seen this behavior:

smb: \> rm foo.txt
NT_STATUS_CONNECTION_DISCONNECTED deleting remote file \foo.txt
NT_STATUS_CONNECTION_DISCONNECTED listing \foo.txt
smb: \> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection
is disconnected now

?

I have tested against 4.6.1 and 4.5.7 with the same results.  I have tried
smbclient and the CIFS kernel client with the same results.  In the logs, I
am seeing this (consistently):

[2017/03/27 19:52:03.375176,  0]
../lib/dbwrap/dbwrap.c:165(dbwrap_check_lock_order)
  Lock order violation: Trying /usr/local/samba/var/locks/file_ntacls.tdb at
1 while /usr/local/samba/var/lock/locking.tdb at 1 is locked
[2017/03/27 19:52:03.376441,  0] ../lib/dbwrap/dbwrap.c:114(debug_lock_order)
  lock order:  1:/usr/local/samba/var/lock/locking.tdb 2:<none> 3:<none>
[2017/03/27 19:52:03.376633,  0] ../source3/lib/util.c:791(smb_panic_s3)
  PANIC (pid 3851): invalid lock_order
[2017/03/27 19:52:03.377786,  0] ../source3/lib/util.c:902(log_stack_trace)
  BACKTRACE: 43 stack frames:
:
:
[2017/03/27 19:52:03.381678,  0] ../source3/lib/dumpcore.c:303(dump_core)
  dumping core in /usr/local/samba/var/cores/smbd

Invalid lock_order.  Hmmm...

Here's the interesting portion of the wire trace:
45  11.656391 ::1 ::1 SMB 154 Delete Request, Path: \install.log
46  11.669512 ::1 ::1 TCP 86  microsoft-ds > 50793 [FIN, ACK] Seq=1744
    Ack=10390 Win=131072 Len=0 TSval=46500697 TSecr=46500683
47  11.669574 ::1 ::1 TCP 86  50793 > microsoft-ds [FIN, ACK] Seq=10390
    Ack=1745 Win=71168 Len=0 TSval=46500697 TSecr=46500697
48  11.669586 ::1 ::1 TCP 86  microsoft-ds > 50793 [ACK] Seq=1745 Ack=10391
    Win=131072 Len=0 TSval=46500697 TSecr=46500697

Basically, the client sends the delete request, the server *performs the
delete* (the file is gone when I check) and then the crash causes the
disconnect.

My smb.conf is set up for a file system that has no support for flock(),
fcntl() or kernel OpLocks.  All client locking requests are being handled
internally by Samba.  This test, however, has been run against an EXT4-based
share with the same results, so I don't believe that this is the result of a
bad interaction with a new FS.

So... has anyone else seen this?

Chris -)-----