Bug 11303 - OS X clients crash when copying file with resource fork to server
Summary: OS X clients crash when copying file with resource fork to server
Status: ASSIGNED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.0
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-31 06:19 UTC by Ralph Böhme
Modified: 2015-06-16 14:23 UTC (History)
1 user (show)

See Also:


Attachments
Image with resource fork (130.52 KB, application/zip)
2015-05-31 06:24 UTC, Ralph Böhme
no flags Details
pcap with vfs_streams_depot, Samba 4.2.0 (480.04 KB, application/octet-stream)
2015-05-31 06:28 UTC, Ralph Böhme
no flags Details
pcap with vfs_fruit, reverted compound response fix (506.36 KB, application/octet-stream)
2015-05-31 06:30 UTC, Ralph Böhme
no flags Details
pcap with vfs_fruit, master (486.91 KB, application/octet-stream)
2015-05-31 06:32 UTC, Ralph Böhme
no flags Details
pcap from copy to Windows8 (338.45 KB, application/octet-stream)
2015-05-31 06:33 UTC, Ralph Böhme
no flags Details
pcap from copy to a Mac (316.21 KB, application/octet-stream)
2015-06-01 09:39 UTC, Ralph Böhme
no flags Details
Sort stream names in vfs_streams_depot (1.83 KB, patch)
2015-06-01 10:28 UTC, Ralph Böhme
no flags Details
pcap with vfs_streams_depot and sorted stream names patch (160.55 KB, application/x-gzip)
2015-06-01 10:29 UTC, Ralph Böhme
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2015-05-31 06:19:18 UTC
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.

smb.conf:
[global]
    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

[fruit]
    path = /Volumes/streams
    vfs objects = catia fruit streams_xattr acl_xattr 

[depot]
    path = /Volumes/streams
    vfs objects = streams_depot acl_xattr
Comment 1 Ralph Böhme 2015-05-31 06:24:24 UTC
Created attachment 11105 [details]
Image with resource fork
Comment 2 Ralph Böhme 2015-05-31 06:28:17 UTC
Created attachment 11106 [details]
pcap with vfs_streams_depot, Samba 4.2.0
Comment 3 Ralph Böhme 2015-05-31 06:30:08 UTC
Created attachment 11107 [details]
pcap with vfs_fruit, reverted compound response fix
Comment 4 Ralph Böhme 2015-05-31 06:32:41 UTC
Created attachment 11108 [details]
pcap with vfs_fruit, master
Comment 5 Ralph Böhme 2015-05-31 06:33:44 UTC
Created attachment 11109 [details]
pcap from copy to Windows8
Comment 6 Ralph Böhme 2015-06-01 09:39:18 UTC
Created attachment 11114 [details]
pcap from copy to a Mac
Comment 7 Ralph Böhme 2015-06-01 10:28:47 UTC
Created attachment 11115 [details]
Sort stream names in vfs_streams_depot
Comment 8 Ralph Böhme 2015-06-01 10:29:42 UTC
Created attachment 11116 [details]
pcap with vfs_streams_depot and sorted stream names patch
Comment 9 Jeremy Allison 2015-06-01 19:11:07 UTC
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 ?
Comment 10 Ralph Böhme 2015-06-15 16:51:54 UTC
(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.
Comment 11 Jeremy Allison 2015-06-15 20:31:51 UTC
(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.