Univention Bugzilla – Bug 30007
Files only partially transfered to Mac OSX 10.8.2 clients
Last modified: 2013-02-01 08:42:23 CET
Created attachment 4978 [details] debuglevel 12 samba logs Files (bigger than 48kb) copied from a samba 4 share (s3fs) get corrupted. Mac OSX gives the error message: "The operation can’t be completed because an unexpected error occurred (error code -8084)." The Mac OSX "console" gives: "Locum[1229]: Connection with distnoted server was invalidate" It looks like the file get transferred correctly as local and remote size are equal, but at some point the local file gets filled up with 0 (in my test case everything above 58493 bytes). Every attempt to copy the file results in a corrupt file with the same md5 hash so copying always end at the same position. It is possible to copy files on the samba share and it is possible to retrieve files from samba 3 (memberserver) share. <http://forum.univention.de/viewtopic.php?f=48&t=2208>
Created attachment 4985 [details] Analysis of the wireshark traces and logs Samba4 is now built in errata3.1-0 with an experimental patch: 4.0.0~rc6-1-errata3.1-0/97_applesmbx_reply_read_and_X_maxcounthigh.patch The critical code block is not present in Samba 3.6.8 (yet), maybe a slightly improved patch can be constructed from a short analysis of the 3.6.8 code before submitting the patch upstream. On the other hand the internal data structures have evolved quite a bit due to the ongoing smb2 work. It's crucial to ensure that this patch does not break file transfers to windows clients. Probably the most direct testcase would be the transfer of a file of exactly 64k, monitored by tcpdump.
Schneller Workaround ist: ucr set samba/large_readwrite=no /etc/init.d/samba4 restart die Shares müssen danach nicht neu gemountet werden.
There is a quick workaround: ucr set samba/large_readwrite=no /etc/init.d/samba4 restart the shares don't need to be remounted for this to take effect.
(In reply to comment #3) > There is a quick workaround: > > ucr set samba/large_readwrite=no > /etc/init.d/samba4 restart > > the shares don't need to be remounted for this to take effect. I can confirm that this workaround fixes the bug. Are there any sideeffects for Mac/Windows-Clients we have to look out for?
With this setting the Samba 4 fileserver does not advertise support for "large reads" (and writes) any more, conforming e.g. to the behavior of Windows 2008R2. One half of this bug was introduced into the samba4 code in September 2011 during a code rework which had the the goal to make the behavior of the samba file server more consistent with that of native Windows (The other half of the bug lies in the implementation of the MacOS SMBX client which writes 64k of zeros to a file when the server unexpectedly returns exactly 0 bytes). Sideeffects: large read/writes can benefit performance, so turning them off does not provide this advantage over e.g. native Windows 2008R2. From the currrent Samba 4 implementation I gather that only smbclient and mounts with enabled unix extensions can benefit from large read/writes anyway. Future releases of samba 4 will probably make the behavior of the samba file server a bit less client specific and might help achieving this without sacrifice of performance. At least we raised awareness of this issue and we surely are interested in a consistent configuration with the best performance and stability possible, so we are trying to support upstream development in this issue.
I think we should at least change the default value or we should fix the issue. Otherwise that will be a problem for every customer/tester who will use the mac client. Let's see how the upstream discussion ends and decide than (errata or 3.1-1).
Upstream bug created with network traces and analysis attached.
The source package samba4 is build now with todays upstream patch. Wireshark shows that the large read request of the MacOSX client is served with optimal efficiency as expected by the client. A testfile was transferred correctly. Advisory: 2013-01-17-samba4.yaml
Big file transfer with - Mac OS X: OK - Win7: OK - Win8: OK - W2k8: OK - W2k12: OK Small file transfer with - Mac OS X: OK - Win7: OK - Win8: OK - W2k8: OK - W2k12: OK errata YAML: OK 3.1-1 changelog: OK 3.1-1 code: OK over Bug #30178
http://errata.univention.de/3.1-errata26.html
Will there be a fix for UCS 3.0?