The fix for bug #13181 introduced a codepath that ultimately results in a call to get_existing_share_mode_lock() on stream while we already have a lock on the base file from another call to get_existing_share_mode_lock(). The error message is:

[2018/05/20 05:35:14.665532,  1] ../source3/locking/share_mode_lock.c:612(get_share_mode_lock)               
  Can not lock two share modes simultaneously 

It is triggered when deleting a file on a share with fruit and goes via:

close_remove_share_mode(): calls get_existing_share_mode_lock() on basefile)
-> delete_all_streams()
-> SMB_VFS_STREAMINFO()
-> fruit_streaminfo_meta_stream(): calls get_existing_share_mode_lock() on basefile:AFP_AfpInfo

Now I only need a good idea how to fix this an preserve that behaviour that if the client writes all 0 to the basefile:AFP_AfpInfo stream, subsequent SMB_VFS_STREAMINFO() don't list the stream anymore.

It seems any possible solution to this requires opening a handle on the stream in fruit_streaminfo_meta_stream() in order to do the check. Hm, maybe truncating to 0 bytes could work...