Bug 2421 - Quickbooks file sharing oplock problem in 3.0.11 and 3.0.12pre2-SVN-build-5654
Summary: Quickbooks file sharing oplock problem in 3.0.11 and 3.0.12pre2-SVN-build-5654
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.11
Hardware: x86 FreeBSD
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-04 20:40 UTC by Mitch
Modified: 2005-10-31 22:09 UTC (History)
3 users (show)

See Also:


Attachments
tethereal - Win2k with oplocks (34.45 KB, text/plain)
2005-10-26 18:01 UTC, Kevin Shanahan (dead mail address)
no flags Details
tethereal - Samba with oplocks (34.42 KB, text/plain)
2005-10-26 18:08 UTC, Kevin Shanahan (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mitch 2005-03-04 20:40:37 UTC
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.

[global]
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"

[test]
        comment = test share
        valid users = u100595 u100977
        path = /tmp/testshare
        read only = no
Comment 1 Justin Maggard 2005-10-14 12:06:54 UTC
Any update on this issue?
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-10-14 12:22:26 UTC
please retest aganist 3.0.20b (or update the version for the bug 
report if you have already and the bug still exists).
Comment 3 Kevin Shanahan (dead mail address) 2005-10-25 18:09:54 UTC
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.
Comment 4 Kevin Shanahan (dead mail address) 2005-10-25 20:01:31 UTC
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.
Comment 5 Kevin Shanahan (dead mail address) 2005-10-25 20:52:15 UTC
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
to bugzilla?

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?
Comment 6 Kevin Shanahan (dead mail address) 2005-10-26 04:30:47 UTC
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.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-10-26 04:45:58 UTC
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.
Comment 8 Kevin Shanahan (dead mail address) 2005-10-26 05:08:55 UTC
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.
Comment 9 Kevin Shanahan (dead mail address) 2005-10-26 18:01:25 UTC
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.
Comment 10 Kevin Shanahan (dead mail address) 2005-10-26 18:08:23 UTC
Created attachment 1545 [details]
tethereal - Samba with oplocks

Hopefully this is the equivalent of attachment 1544 [details] with Samba as the server
instead (192.168.0.249)
Comment 11 Kevin Shanahan (dead mail address) 2005-10-31 16:24:18 UTC
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.

e.g. Win2k:

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

e.g. Samba:

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
...etc...
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.
Comment 12 Jeremy Allison 2005-10-31 18:42:20 UTC
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
later build.
Jeremy.
Comment 13 Kevin Shanahan (dead mail address) 2005-10-31 21:42:55 UTC
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.
Comment 14 Jeremy Allison 2005-10-31 22:09:58 UTC
Fixed in 3.0.20b.
Jeremy.