The Samba-Bugzilla – Bug 3927
Quickbooks / Byte Range Locking / Delayed write failed
Last modified: 2008-05-09 08:38:49 UTC
This seems related to bug#3587
(I am unsure whether this should be reported seperately)
I had the "byte range" issue documented in bug#3587
The "auto cleaning patch" of the brlock.tdb file solved my problem.
I seemed to pick up a new problem though.
After a few days, when opening Quickbooks, Quickbooks complains about "unable to create image file". This is a "shared access lock file" with q QBI extention.
Screen shot as below.
This happens from all PCs.
A simple restart of Samba solves the problem for a few days. It then re-occurs.
I ran the following versions of samba:
Version Problem exists
3.0.22 No (90% sure)
3.0.23rc2 with Volker Patch from bug #3587 Yes
A level 100 log file of PC trying to open Quickbooks while failure occurs is available at:
(In reply to comment #0)
> Version Problem exists
> 3.0.22 No (90% sure)
> 3.0.23rc2 Unsure
> 3.0.23rc2 with Volker Patch from bug #3587 Yes
> 3.0.23rc3 Yes
> 3.0.23 Yes
Guys, this is not funny. You seem to have tested rc3, found a problem and did *NOT* report it? Why do you think are we doing the release candidates?
> > 3.0.23rc2 with Volker Patch from bug #3587 Yes
> > 3.0.23rc3 Yes
> > 3.0.23 Yes
> Guys, this is not funny. You seem to have tested rc3, found a problem and did
> *NOT* report it? Why do you think are we doing the release candidates?
Apologies for this one! It happened infrequently enough that I couldn't be sure. I did not want to blame Samba if it wasn't responsible. There were also other network issues that needed to be sorted first. This is the first time that I could generate a log with an otherwise stable network. :-(
(My report of after a "day or so" above would probably me more accurate if I say a "few days, maybe even a week" before it fails again.)
(In reply to comment #2)
Happened again today. Exactly the same symptoms. I upgraded to 3.0.21a in the hopes that it might get fixed. As an upgrade requires a smb restart, it will be another week or two before I know if the issue is resolved.
> Happened again today. Exactly the same symptoms. I upgraded to 3.0.21a in the
> hopes that it might get fixed. As an upgrade requires a smb restart, it will
> be another week or two before I know if the issue is resolved.
Another update. Happened again approx 24 hours later. (with 3.0.23a).
Please let me know if you need any further info.
The "Delayed write fail" message usually appears when the network has a problem and the client disconnects. It will reconnect and continue, but lost the write in progress. Do you see any messages to that effect in the smbd logs ? This doesn't look like a byte range lock issue to me (we nailed that with the self-cleaning patch) but an ordinary network reliability problem now.
(In reply to comment #5)
> The "Delayed write fail" message usually appears when the network has a problem
> and the client disconnects.
Normally I would agree. This time not.
(Remeber that Quickbooks saves data in a .QBW file and uses a .QBI file to handle "concurrent access").
Troubleshooting as follows:
- Client phones and complains.
- You can now open quickbooks, and get the exact error as seen here:
- If you close quickbooks, and re-open, exactly the same happens.
- You cannot open the quickbooks data from ANY PC.
- You can open any other files from all PCs.
- a simple "killall smbd ; smbd" solves the problem.
- it happens again (anything from 24 hours to 2 weeks later).
This only started happening at the same time as I upgraded the samba from 3.0.21c in order to solve the byte rangle locking issue.
If needed I can downgrade to 3.0.21c (or 3.0.22) to see if the problem goes away, but then I get the byte range locking issue back.
Happened again today.
In deperation I now downgraded to 3.0.21c.
I plan on using the 3.0.23 smbstatus -B to get rid of invalid BR locks when they occur. Will log any more failures here.
We used samba the latest: 3.0.25c and we have this isse after some of writing a large files on samba share we have: Delayed write failed bla bla of course in polish language.
This files were written to samba share under pure windows .net 2.0 application. But i have seen this error when i was working in DOS application written in FoxPro 2.6 in another location !! (another workplace, anothr switches, network equipment). After some times of working my DOS foxpro application kick to windows and near of systray i saw this info about delayed write failed to my samba share: samba version: 3.0.25b but as you can see on samba 3.0.25c this error also occured. Soory, but no logs are attached.
I thinks some things went wrong and there is still problem with this matter.
On this 2 serwers is centos4.5 installed and samba from sernet.
I found on the internet, that some folks in POLAND have some problems with this issue - large files under thunderbird.
We are afflicted by this issue as well running Debian Etch. The only application with which this has occured for us, was WinRAR. (Unarchiving).
It seems another bloke using CentOS 5.1 has a similar issue: http://bugs.centos.org/view.php?id=2678
(In reply to comment #9)
> We are afflicted by this issue as well running Debian Etch. The only
> application with which this has occured for us, was WinRAR. (Unarchiving).
Sorry, I forgot to mention our Samba version:
We seem to have the same Problem.
Specially when working with large Database Files but also with small files Windows displays a small pop up with the Message "Delayed Write Failed".
Samba 3.0.28, Kernel 2.6.24 on Gentoo
Samba is acting as Domain Controller for ~30 Workstations.
The Workstations are all Windows XP 32bit sp2
This seems also to happen with cifs from another Linux box:
May 9 14:33:03 CIFS VFS: server not responding
May 9 14:33:03 CIFS VFS: No response to cmd 47 mid 61863
May 9 14:33:03 CIFS VFS: Write2 ret -11, wrote 0
May 9 14:33:06 CIFS VFS: No response to cmd 47 mid 39910
May 9 14:33:06 CIFS VFS: Write2 ret -11, wrote 0
May 9 14:33:06 CIFS VFS: Write2 ret -9, wrote 0
May 9 14:33:06 CIFS VFS: Write2 ret -11, wrote 0
This may be the same problem as in bug #4763