smbd process (crashes and dumps and) disconnects on file delete.
amit kumar
amitkuma at redhat.com
Tue Mar 28 05:01:43 UTC 2017
Hello,
What's seen in bt?
At 1st look it seems, samba client is trying to acquire lock before
deletion.
I cannot repro this Issue at my local system, this is my config:
# vim /etc/samba/smb.conf
[global]
workgroup = WORKGROUP
security = user
passdb backend = tdbsam
log level = 9
log file = /var/log/log.*
[myshare-home-fred]
path = /home/fred
browsable = yes
guest ok = yes
read only = no
create mask = 0755
$ smbclient //<ip-smb-server>/myshare-home-fred -U fred
smb: \> rm file1 <=Deleted
$
Note to delete file,directory must be owned by logging user..
Thanks
On 03/28/2017 12:27 AM, Christopher R. Hertel via samba-technical wrote:
> 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 -)-----
>
--
Thanks
Amit Kumar
There are three ways to get something done:
(1) Do it yourself.
(2) Hire someone to do it for you.
(3) Forbid your kids to do it.
More information about the samba-technical
mailing list