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

Wed Mar 29 01:18:31 UTC 2017

By the way, this is bug #11761, first reported last year.  Glad I found it.  :)

I've tested Volker's suggested fix and it appears to work.

Chris -)-----

On 03/28/2017 02:46 PM, Christopher R. Hertel via samba-technical wrote:
> I've narrowed this down to acl_tdb.  If I don't load that one module, there
> is no crash on file deletion.  If I do load that module, with or without
> xattr_tdb, then the crash occurs on file delete.
> 
> I have just testing using acl_xattr instead of acl_tdb and that works just
> fine, so I can continue working on my project.
> 
> I do believe, however, that I've uncovered a bug of some sort in the acl_tdb
> module.
> 
> Chris -)-----
> 
> 
> On 03/28/2017 12:05 PM, Christopher R. Hertel via samba-technical wrote:
>> 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.
>>>
>>
> 