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

[amit kumar]

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.