SAMBA (CIFS/9000 Server) Problems

[Alzhy]

A.01.08 Version Installed on 11.0 Server. Windows clients are NT 4.0 SP6 and Win2K SP3:

We've been experiencing problems with Windows clients opening/reading multiple files just suddenly being denied access or experiencing file read errors. One typical SMBD log follows:

[2002/10/16 12:54:26, 0] smbd/oplock.c:(758)
oplock_break: receive_smb error (Error 0)
oplock_break failed for file ORGN/YP/PDF/pbd_orgn_1102_yp__0430__02.pdf (dev =
40030003, inode = 8976, file_id = 1511).
[2002/10/16 12:54:26, 0] smbd/oplock.c:(843)
oplock_break: client failure in break - shutting down this smbd.
[2002/10/16 14:57:11, 0] smbd/oplock.c:(758)
oplock_break: receive_smb error (Error 0)
oplock_break failed for file ORGN/YP/PDF/pbd_orgn_1102_yp__0553__02.pdf (dev =
40030003, inode = 9301, file_id = 1001).
[2002/10/16 14:57:11, 0] smbd/oplock.c:(843)
oplock_break: client failure in break - shutting down this smbd.


Our NFILE is 4096 and NFLOCKS is 1200, Max clients is less than 50 with no more than 20 connecting at any one time. Is this a known problem or just a tuning issue? All defaults in smb.conf config (oplocks, etc...). Contemplating on going to A.01.09.5 (Mar 2003).. Any help would be appreciated.. Thanks!

[Geoff Wild]

Try:

keepalive = 0

"The value of the parameter (an integer) represents the number of seconds between keepalive packets. If this parameter is zero, no keepalive packets will be sent. Keepalive packets, if sent, allow the server to tell whether a client is still present and responding.

Keepalives should, in general, not be needed if the socket being used has the SO_KEEPALIVE attribute set on it (see socket options). Basically you should only use this option if you strike difficulties.

Default: keepalive = 300"

Rgds...Geoff

[Darren Prior]

Hi,

Well, I'd consider going to the later version anyway - there was a recent security alert and the latest version is the only one unaffected.

It's also worth determining if you actually require oplocks for those particular types of files. There's some good info on oplocks in the Using Samba book from O'Reilly - also available via SWAT on your CIFS server. If not, I'd consider disabling oplocks on that share.

regards,

Darren.

[Steven E. Protter]

A good first step is to download the latest release and install it.

There are known problems with the release you are on including a security flaw that Berlene pointed out a few weeks ago.

I've spoken to a half dozen people in these forums who have solved problems similar to yours with the upgrade.

From a prior thread:

docs

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B8725-90021/B8725-90021_top.html&con=/hpux/onlinedocs/B8725-90021/00/00/8-con.html&toc=/hpux/onlinedocs/B8725-90021/00/00/8-toc.html&searchterms=Setup%7cInstallation%7cCIFS/9000&queryid=20030512-200357

Install Guide.

http://docs.hp.com/hpux/onlinedocs/netcom/cifs_client_manual.pdf

The software

CIFS/9000

Here is a link to the free software:

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B8725AA

The reference.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x653663f96280d711abdc0090277a778c,00.html

Good Luck,

SEP

[Alzhy]

Well, Thanks Darren/Geoff... our clients mostly are actually failing opening up a bunch of PDF files from Windows Workstations using Acrobat Reader 5.x.... Workstations are either LAN or WAN but the failures (denials/read errrors) do not discriminate between the two...

[Darren Prior]

Hi Nelson,

In that case you could consider using the "veto oplock files" option - where you can list specific filenames that should not use oplocks.

ie:

veto oplock files = /*.pdf/

I'd do some testing to see if it has any negative effect, though I'd doubt it as the files are only being read hence oplocking isn't important.

regards,

Darren.

[Don McCall_1]

It would be GOOD to go to the latest cifs server version anyway, since there are security fixes in that release. Be aware that A.01.08 is based on Samba 2.2.3a, whereas A.01.09.05 is based on Samba 2.2.5, lots of bugfixes and code changes (hopefully for the better). As to your specific problem, I would suggest that you turn oplocks OFF in general on samba. In my experience they cause more harm than good in the long run. If you have a readonly share (I would assume your pdf files are not being opened for modification, but of course this could be wrong), setting FAKE oplocks (fake oplocks=yes) in the share definition of your smb.conf file will allow for client side caching of these files, and may be worth the performance increase. Basically, oplocks are very finicky, and if for ANY reason the smbd or client the smbd is working on behalf of cannot/does not respond to an oplock break, you get this kind of behavior. And if you are getting oplock break messages, then it essentially means that you are not getting a lot of performance benefit from the oplock anyway, since (esp with big files) processing the oplock break is going to require the client to throw away his cached copy of the file and re-acquire it from the server anyway - so now he's read the file twice. If it's a read only file, that's a waste.
Hope this helps.