Bug 9572 - File corruption during SMB1 read by Mac OSX 10.8.2 clients
File corruption during SMB1 read by Mac OSX 10.8.2 clients
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: File services
4.0.0rc6
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-18 11:40 UTC by Arvid Requate
Modified: 2013-08-12 11:27 UTC (History)
4 users (show)

See Also:


Attachments
TCP traces of MacOSX read from three servers (S4,W2k8R2,MacOSX) (924.39 KB, application/x-gtar)
2013-01-18 11:44 UTC, Arvid Requate
no flags Details
git-am fix for 4.0.x and master (3.63 KB, patch)
2013-01-23 18:19 UTC, Jeremy Allison
no flags Details
git-am fix for master and 4.0.x (3.61 KB, patch)
2013-01-23 18:42 UTC, Jeremy Allison
no flags Details
git-am fix for master and 4.0.x (3.81 KB, patch)
2013-01-24 17:10 UTC, Jeremy Allison
metze: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate 2013-01-18 11:40:29 UTC
Recent MacOSX clients trigger an issue in the SMB reply_read_and_x function of the Samba4 smbd file server code which leads to a corruption of files copied from a Samba4 file server to a recent MacOSX client (I guess using their replacement SMBX client code). In contrast file transfers from Samba 3.6.8 file servers to MacOSX are ok.

As a workaround the Samba parameter "large readwrite" can be set to "no" to avoid the misbehaviour of server and client.
Comment 1 Arvid Requate 2013-01-18 11:44:08 UTC
Created attachment 8447 [details]
TCP traces of MacOSX read from three servers (S4,W2k8R2,MacOSX)

The trace of the read from the Samba4 RC6 and the analysis of the resulting target file show that the corruption occurs in these stages:

1. The MacOSX client asks for 129024 bytes (0x1f800) and the Samba 4 file server returns 0x0f800 bytes.
2. The MacOSX client asks for 67584 bytes (0x10800) and the Samba 4 file server returns 0x00800 bytes. All fine to this point, the first 64k have been written correctly to the target file on the client.
3. Next the MacOSX client asks for exactly 64 kb and the Samba 4 file server returns 0 bytes.
4. The MacOSX client then writes 64k of zeros into the file, considers the 64k block read, increases the offset and the procedure continues again at point 1. This is clearly a client side bug which ultimately corrupts the files.

A quick tcpdump showed that the MacOSX client does not ask for large reads  when copying files from a Windows 2k8R2 (non-DC workstation), maybe the Windows server does not advertise that it supports large reads.
Comment 2 Stefan Metzmacher 2013-01-18 12:16:46 UTC
Does this also happens with "unix extentions = no"?
Comment 3 Arvid Requate 2013-01-18 12:52:05 UTC
Files are transferred correctly with "unix extentions = no".
Comment 4 Stefan Metzmacher 2013-01-18 12:54:25 UTC
(In reply to comment #3)
> Files are transferred correctly with "unix extentions = no".

Then the MacOS client seems to look only at the CAP_UNIX in order to change
it's behavior.
Comment 5 Andrew Bartlett 2013-01-21 07:52:57 UTC
I've looked at the traces in more detail, and essentially I agree.  The mac does a QueryFSInfo, and presumably honours the CIFS_UNIX_LARGE_READ_CAP there, but doesn't send back the SetFSInfo smbd is looking for. 

(More detailed discussion on the list)
Comment 6 Jeremy Allison 2013-01-23 18:19:08 UTC
Created attachment 8471 [details]
git-am fix for 4.0.x and master

Fix I think we need for master and 4.0.x.

Jeremy.
Comment 7 Jeremy Allison 2013-01-23 18:42:13 UTC
Created attachment 8472 [details]
git-am fix for master and 4.0.x

Fixed the function signature - server_will_accept_large_read() doesn't use the req arg.
Jeremy.
Comment 8 Jeremy Allison 2013-01-24 17:10:28 UTC
Created attachment 8477 [details]
git-am fix for master and 4.0.x

Updated with the comment change that Metze requested.

Jeremy.
Comment 9 Jeremy Allison 2013-01-25 22:23:46 UTC
Comment on attachment 8477 [details]
git-am fix for master and 4.0.x

Already went into master. Just needs a +1 for 4.0.next.
Comment 10 Stefan Metzmacher 2013-01-26 13:39:27 UTC
Comment on attachment 8477 [details]
git-am fix for master and 4.0.x

Looks, good.

Karolin, please
git cherry-pick -x -2 996a10cdea4a1ea23bc86c8bc57c4ca02e285b17
Comment 11 Karolin Seeger 2013-01-28 10:16:18 UTC
Pushed to autobuild-v4-0-test.
Comment 12 Karolin Seeger 2013-01-28 19:07:30 UTC
Pushed to v4-0-test.
Closing out bug report.

Thanks!