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)
-> 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...
Fwiw, this should have no user visible impact.