OS X 10.9.5 and 10.10.2 clients crash when copying file with resource fork to server.
The file is an Photoshop image with a large resource fork. I'm enabling named streams support in Samba and tested with fruit/streams_xattr and streams_depot, both result in the same crash.
Seems to always happen at a point where we returned streaminfo for the fully copied file. Sometimes there's a subsequent strange stream open where the client requests the "AFP_Resource" stream on the *base directory, which doesn't make sense at all and indicated that at this point something went wrong.
Other traces show the last response is exactly the streaminfo.
Tested with Samba 4.2.0, 4.2.2 and master. I was initially suspecting the recent compound response padding changeset introduce a regression, but this is reproducible with vanilla 4.2.0.
This works fine against a Windows or Mac SMB server.
server role = standalone
log file = /var/log/samba.log
debug pid = yes
log level = 1
store dos attributes = yes
read only = no
ea support = yes
idmap config * : backend = tdb
idmap config * : range = 10000-20000
smb2 leases = yes
kernel change notify = no
fruit:nfs_aces = no
fruit:aapl = no
path = /Volumes/streams
vfs objects = catia fruit streams_xattr acl_xattr
path = /Volumes/streams
vfs objects = streams_depot acl_xattr
Created attachment 11105 [details]
Image with resource fork
Created attachment 11106 [details]
pcap with vfs_streams_depot, Samba 4.2.0
Created attachment 11107 [details]
pcap with vfs_fruit, reverted compound response fix
Created attachment 11108 [details]
pcap with vfs_fruit, master
Created attachment 11109 [details]
pcap from copy to Windows8
Created attachment 11114 [details]
pcap from copy to a Mac
Created attachment 11115 [details]
Sort stream names in vfs_streams_depot
Created attachment 11116 [details]
pcap with vfs_streams_depot and sorted stream names patch
Might it be an alignment issue with the streaminfo reply ? Does the OS X client log anything about the streaminfo reply before it goes down ?
(In reply to Jeremy Allison from comment #9)
Padding looks good. I've been staring at traces bit by bit together with metze for hours and we couldn't spot anything that would explain this.
(In reply to Ralph Böhme from comment #10)
Ok, the thing to do is to study the MacOSX -> MacOSX traces and look for differences. I've had to do this in the past, it can take a lot of time, but the fix is in there.
Probably related: https://jamfnation.jamfsoftware.com/pipermail/casper/attachments/20080416/b712de25/discussion.html?id=14768