smbd panic at find_oplock_types().

Jeremy Allison jra at
Tue Sep 9 21:22:20 MDT 2014

On Tue, Sep 09, 2014 at 02:23:29PM -0700, Hemanth Thummala wrote:
> +       if (req != NULL) {
> +               set_share_mode(lck, fsp, get_current_uid(conn),
> +                               req->mid,
> +                               fsp->oplock_type);
> +       }
> This way, we will never add internal shared mode locks to data base.
> Want to check with you before I really test these changes. Please correct
> me I am wrong.

Yeah, there is an interaction between base file and stream
share modes we need to get right.

>From source4/torture/raw/streams.c:

 *  Test FILE_SHARE_DELETE on streams
 * A stream opened with !FILE_SHARE_DELETE prevents the main file to be opened
 * The main file opened with !FILE_SHARE_DELETE does *not* prevent a stream to
 * be opened with SEC_STD_DELETE.
 * A stream held open with FILE_SHARE_DELETE allows the file to be
 * deleted. After the main file is deleted, access to the open file descriptor
 * still works, but all name-based access to both the main file as well as the
 * stream is denied with DELETE pending.
 * This means, an open of the main file with SEC_STD_DELETE should walk all
 * streams and also open them with SEC_STD_DELETE. If any of these opens gives
 * SHARING_VIOLATION, the main open fails.
 * Closing the main file after delete_on_close has been set does not really
 * unlink it but leaves the corresponding share mode entry with
 * delete_on_close being set around until all streams are closed.
 * Opening a stream must also look at the main file's share mode entry, look
 * at the delete_on_close bit and potentially return DELETE_PENDING.

And remember, you can open a stream on a different connection
to the open on the base file - which would map to a separate
smbd - so the share mode entry is needed.


More information about the samba-technical mailing list