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

Tue Mar 28 19:46:54 UTC 2017

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.
>>
> 