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
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 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?
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 instead (192.168.0.249)
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.
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.
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. Jeremy.