As per guidance from simo, I cc'd jeremy.
I've got the SVN loaded on a test server - if there is a patch to test, I am a
willing tester. Also if logs are helpful, let me know.
When the second user tries to open the file, quickbooks says the file is
corrupt or is not a quickbooks file - dumb error message - but turning off
oplocks or setting veto oplock files is a work around.
realm = MY.DOMAIN
workgroup = TSDEMO
security = ADS
netbios name = SLIM1
bind interfaces only = yes
interfaces = 10.1.0.4/8
#log file = /usr/local/samba/var/smbd-%U.log
#log level = 10
log file = /usr/local/samba/var/smbd-%G.log
username map = /usr/local/samba/lib/users.map
panic action = "/bin/sleep 90000"
comment = test share
valid users = u100595 u100977
path = /tmp/testshare
read only = no
Any update on this issue?
please retest aganist 3.0.20b (or update the version for the bug
report if you have already and the bug still exists).
I'm also seeing this problem using 3.0.14a from Debian Sarge (x86) using
Quickbooks Pro 2005/2006.
From my initial tests it seemed that disabling oplocks on the share didn't help.
It does work on our Win2000 server, so I'm going to grab some traces with
ethereal for both scenarios and attach them here. Hopefully that's the right
thing to do, rather than creating separate bug report.
Sorry, disabling oplocks on the Samba server actually does enable it to work. I
must have forgotten to reload/restart properly on the last test.
Okay, I have captured the information from two sessions; one trying to use the
data file on a Windows 2000 share, and the other on a Samba (3.0.14a) share. The
method I used was:
- Start capture on server (tethereal)
- Start quickbooks on client 1, open the data file
- Start quickbooks on client 2, open the data file
- Stop capture
The capture files are about 1.5MB compressed each - is it okay to upload these
Would it be useful to instead just to start capturing after client 1 already has
the file open or do you need to see the activity leading to that point as well?
I should have thought of this before, but I just realised that it's possible
that some data in the captures needs to be kept private. It would be better if I
could send the files privately.
If disabling oplocks works in both a Samba and Windows 2000 environment,
what is left to examine? We behave exactly like Windows in this case.
Sorry, I wasn't clear.
Windows 2000 with oplocks enabled - works.
Samba 3.0.14a with oplocks enabled - doesn't work.
Samba 3.0.14a with oplocks disabled - works.
I didn't actually test Win2000 server with oplocks disabled. I was just offering
to provide some data for you to look at if you wanted to see what's different
between Win2k and Samba behaviour with oplocks enabled.
Created attachment 1544 [details]
tethereal - Win2k with oplocks
This is a small snippet of the captured data from the Win2000 server.
192.168.0.252 = Win2000 Server
192.168.0.120 = WinXP client 1
192.168.0.54 = WinXP client 2
Client 1 already has already opened the quickbooks data file on the Windows
2000 share. This snippet is from just after the second client attempts to open
the file. Not that I really know exactly what I'm looking at, but it seemed to
be the first place I could see where the behaviour deviated between Samba and
Win2k. In this sample, the Win2k sever ends up saying "Oplock not granted" to
the "NT Create AndX" request from the client. In the next sample I'll attach,
the Samba server actually does grant the oplock.
Created attachment 1545 [details]
tethereal - Samba with oplocks
Hopefully this is the equivalent of attachment 1544 [details] with Samba as the server
Here's something that might be of significance - from the same capture files as
I used for the excerpts attached previously, following on from that point,
Quickbooks tries to open the data file and read from it. In the Win2k case, the
client does three requests for 256 bytes, with the third request failing. In the
Samba case, the client requests 4096 bytes which fails immediately, but the
client keeps retrying that request many times before giving up. That may be the
point where Quickbooks throws up the error message quoted by the original reporter.
Frame 9706 Read AndX Request, FID: 0xc003, 256 bytes at offset 0
Frame 9707 Read AndX Response, FID: 0xc003, 256 bytes
Frame 9708 Read AndX Request, FID: 0xc003, 256 bytes at offset 1
Frame 9709 Read AndX Response, FID: 0xc003, 256 bytes
Frame 9710 Read AndX Request, FID: 0xc003, 256 bytes at offset 512
Frame 9711 Read AndX Response, Error: STATUS_FILE_LOCK_CONFLICT
Frame 9712 Close Request, FID: 0xc003
Frame 9713 Close Response
Frame 10623 Read AndX Request, FID: 0x25f8, 4096 bytes at offset 0
Frame 10624 Read AndX Response, Error: STATUS_FILE_LOCK_CONFLICT
Frame 10625 Read AndX Request, FID: 0x25f8, 4096 bytes at offset 0
Frame 10626 Read AndX Response, Error: STATUS_FILE_LOCK_CONFLICT
Frame 11652 Close Request, FID: 0xc003
Frame 11653 Close Response
Also, in the samba case the the following showed up just afterward (couldn't
find anything like this in the Win2k log):
Frame 11678 NT Create AndX Request, Path: \path\to\quickbooks-data.qbw
Frame 11680 NT Create AndX Response, Error: NT_STATUS_SHARING_VIOLATION
After that there is a pause before more frames are captured, so I think that's
where the error dialog popped up.
Can you test this against Samba 3.0.20b please ? Also, your ethereal traces are
text dump outputs - these are useless - we need the *raw* network capture data
(the exact binary dump of what ethereal captured). There have been some share
mode and oplock fixes between 3.0.14 and 3.0.20b so it's worth while trying on a
Thanks Jeremy, you were right. This seems to be fixed in 3.0.20b.
Going back to what I saw in comment #9, Samba now does not grant the oplock
where it did before so it now matches Win2k behavior and Quickbooks is happy.
Fixed in 3.0.20b.