> Does any one has idea if Samba supports client side oplocks. > i.e if we are using "smbclient"no, it doesn't. In the next release you can enable it by editing client.c and adding one line, but that's just for my testing, it has no use for real file transfers. I just added it to the underlying SMB client library in order to stress test the oplock code using smbtorture. why do you want it?
pjoshi@wipinfo.soft.net wrote:> Does any one has idea if Samba supports client side oplocks. > i.e if we are using "smbclient"Andrew Tridgell replied: | In the next release you can enable it by editing | client.c and adding one line, but that's just for my testing, it has | no use for real file transfers. I just added it to the underlying SMB | client library in order to stress test the oplock code using | smbtorture. | why do you want it? It would be useful to provide a means of updating files which are oplocked from a Unix server and having the clients see the updates. This is a recurring problem with other SMB servers, as well as with Samba servers without kernel oplocks. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com
Hi Does any one has idea if Samba supports client side oplocks. i.e if we are using "smbclient" If yes how to enable/disable it. Where can we get the details. Thanks Pankaj
Dear ..., I would ask a question on such matter, sorry when it's the wrong way.... The next errors got i ... It makes Samba untrustable, but it can't be ... [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. We are using RedHat 6.1, with de Samba 2.0.5a init. When you have a solution, help me please.... Greatings, Werner E. Korpershoek Ps. The question to samba@lists.samba.org has no solution, one person answered : He had the same question - in better English - : > Werner,> > > > I read your post about the oplock problem. > > > > I am having the EXACT same problem and was wondering if anyone ever > > responded to your post. I posted the same question and didn't > > receive any > > responce. > > > > This error just showed up one day and is making life misserable. > > > > Thank you > > > > Ron Bombard > > ronb@nativetextiles.com
> 1. Oplock (Werner E. Korpershoek)[...]> From: "Werner E. Korpershoek" <wek@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.