Oplock

[Stefan Arbeiter]

>    1. Oplock (Werner E. Korpershoek)
[...]
> From: "Werner E. Korpershoek" <wek at weksupport.nl>
[...]
> [2001/01/04 20:05:37, 0] smbd/oplock.c:oplock_break(905) oplock_break resend
> [2001/01/04 20:05:47, 0] smbd/oplock.c:oplock_break(905) oplock_break resend
> [2001/01/04 20:05:57, 0] smbd/oplock.c:oplock_break(905) oplock_break resend
> [2001/01/04 20:06:07, 0] smbd/oplock.c:oplock_break(922) oplock_break:
> receive_smb timed out after 30 seconds.
> oplock_break failed for file groenten20002001/10x10x1grodanbestelling.xls
> (dev = 341, inode = 376103).
> [2001/01/04 20:06:07, 0] smbd/oplock.c:oplock_break(992) oplock_break:
> client failure in break - shutting down this smbd.
  ^^^^^^^^^^^^^^^^^^^^^^^
> [2001/01/04 20:06:07, 1] smbd/service.c:close_cnum(557) cvr (0.0.0.0) closed
> connection to service Administratie
>
> Espescially it is often bij one user.

I had this problem _very_ often - eyery time the cause was faulty 10 Base
2 (coax) cables or UTP-cables someone had been tampering with ...

Sometimes each smbd process would shut down (producing exactly the same
error messages as yours), until only one client was  operating, and as
soon as the user started a application on a share, this one would also
fail. People would login  again/and  or reboot, it would work fine for
some time, then it would start all over again.

When the local admin did finally check connectivity between the clients,
he found out he couldn't get a sinlge ping trough, and had to replace
almost half of all the cables.

After this however, now and then an oblock break request would fail,
and a client would have problems running an app from a share. Checking
log.smb for the failure and just walking to the pc of the user and
replacing the cable did work.

However, after UTP-cabling was installed, the problem surfaced again.