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.
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.
Does this also happens with "unix extentions = no"?
Files are transferred correctly with "unix extentions = no".
(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.
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)
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.
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.
Created attachment 8477 [details] git-am fix for master and 4.0.x Updated with the comment change that Metze requested. Jeremy.
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 on attachment 8477 [details] git-am fix for master and 4.0.x Looks, good. Karolin, please git cherry-pick -x -2 996a10cdea4a1ea23bc86c8bc57c4ca02e285b17
Pushed to autobuild-v4-0-test.
Pushed to v4-0-test. Closing out bug report. Thanks!