[Samba] Maximum number of LANMAN Work Items and concurrent connections from IIS 6.0 to Samba

[S. J. van Harmelen]

Jeremy,

Aldo I would still very much like you to take a look (to confirm that it
is not Samba causing the problem), I'm affraid I already know what the
problem is.

We are using DFS (distributed file system) to connect to our Samba
server. Now when I change the path from DFS to a standard UNC path and
refresh the site... The error is gone...

So I think I'm going to call M$ about this one. I already searched
google, but that didn't give me any leads...

Though I do have another question! Can you tell me why changing the
'change notify timeout' to say 5 seconds isn't a good idea? At least,
that's what I read around the internet (google again ;). We need this
setting to be something like 5 seconds for our setup to work.

Regards,

Sander



On vr, 2006-06-30 at 09:23 -0700, Jeremy Allison wrote:
> On Thu, Jun 29, 2006 at 05:45:24PM +0200, S. J. van Harmelen wrote:
> > Hey there folks!!
> > 
> > I have a question about the maximum number of LANMAN Work Items and
> > concurrent connections from IIS 6.0 to Samba.
> > 
> > We have a server for shared windows webhosting running Windows 2003 with
> > IIS 6.0 (with ASP.NET 2.0) connecting to debian 3.1 with Samba 3.0.22
> > (functioning as a fileserver).
> > 
> > At this moment there are about 250 sites running on this server. Now
> > when we make a request to site x (which is using ASP.NET 2.0) we get the
> > following error:
> > 
> > "Failed to start monitoring changes to \\server\websitedirectory...
> > because the network BIOS command limit has been reached"
> > 
> > Now I know there is a registry setting in Windows 2003 that controls
> > these values, but I can't seem to find how to configure this in Samba.
> > 
> > As far as I understand, Samba by default is configured for unlimited
> > connections. So what am I missing?
> 
> Yes, there are no hardcoded limits in Samba. Can you post an ethereal
> trace of the connection failure ? Or a smbd debug level 10 log so we
> can work out what might be going on ?
> 
> Jeremy.