Bug 13487 - vfs_fruit triggers "Can not lock two share modes simultaneously" error message
Summary: vfs_fruit triggers "Can not lock two share modes simultaneously" error message
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-06-26 15:11 UTC by Ralph Böhme
Modified: 2018-10-01 08:55 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2018-06-26 15:11:17 UTC
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()
-> 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...
Comment 1 Ralph Böhme 2018-06-26 15:16:19 UTC
Fwiw, this should have no user visible impact.