smbd panic at find_oplock_types().

Hemanth Thummala hemanth.thummala at
Tue Aug 5 12:22:19 MDT 2014

These are user files not internal/temp files. Yeah stat open checks for
non-zero access mask. But I have seen at one place where we send zero
access mask along NO_OPLOCK flag.

In create_file_unixpath():
/* Open the base file. */
status = create_file_unixpath(conn, NULL, smb_fname_base, 0==> Access mask,
      0, 0, 0==> oplock, 0, 0, NULL, NULL,
      &base_fsp, NULL);

But this will happen only when the request comes for stream files. But I
feel we should mark access mask non-zero so that we can filter these shared
mode locks with is_stat_open().
In my case, file doesn't have any streams. So I am ruling this possibility
out. But thought of showing that we have a case where we are using zero
access mask for stat/internal opens.


On Tue, Aug 5, 2014 at 1:53 AM, Volker Lendecke <Volker.Lendecke at>

> On Mon, Aug 04, 2014 at 03:42:55PM -0700, Hemanth Thummala wrote:
> > Hi,
> >
> > We are using samba 3.6.12+ stack. And we are hitting this smbd panic
> > customer site frequently(atleast once in a week). Couldn't reproduce this
> > issue in house but collected few details. This issue happens only with
> > application files.
> Is this a user file or some internal print file? The
> access_mask=0 in the second share entry is really
> surprising. I could see a stat open not breaking the batch
> oplock, but that does have some access mask bits set. See
> is_stat_open(). Really weird.
> Volker

More information about the samba-technical mailing list