smbd process (crashes and dumps and) disconnects on file delete.
Christopher R. Hertel
crh at samba.org
Mon Mar 27 18:57:32 UTC 2017
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 -)-----
More information about the samba-technical
mailing list