smbd panic at find_oplock_types().
hemanth.thummala at gmail.com
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.
/* Open the base file. */
status = create_file_unixpath(conn, NULL, smb_fname_base, 0==> Access mask,
0, 0, 0==> oplock, 0, 0, NULL, 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 sernet.de>
> 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.
More information about the samba-technical