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

[Christopher R. Hertel]

Amit, et. al.,

I don't think it's a client-side issue.  My testing has mostly ruled in
favor of this being a corner-case on the server side, driven by my
particular configuration requirements.

Here's my base config:

[global]
  read only  = no
  server min protocol = NT1
  server max protocol = SMB3
  kernel oplocks      = no
  kernel share modes  = no
  posix locking       = no
  kernel change notify = no
  oplocks         = yes
  level2 oplocks  = yes
  smb2 leases     = yes
  durable handles = yes
  vfs objects     = xattr_tdb, acl_tdb
  ea support      = yes
  store dos attributes = yes

As you can see, my goal is to cleanly contain all locking within Samba
itself, and not rely on the underlying file system.  The same is true for
inotify, EAs, and Windows ACLs.  The file system does not yet have support
for these features, but Samba *should* be able to manage them on its own
using the settings above.

If someone sees an error in the above config, please let me know.

If you add shares to the above, you should be able to reproduce the problem
I am seeing.  If not... then things are weirder than I had imagined.

Chris -)-----


On 03/28/2017 12:01 AM, amit kumar wrote:
> 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.
>