From Mac OS, files appear corrupt over AFP share, but fine on CIFS share
I recently upgraded to FreeNAS 9.3 (FreeNAS-9.3-STABLE-201506162331) from 9.2.
Now when I view Canon raw photos (CR2) from my zpool over AFP from MacOS, many images appear corrupted. Either the image cuts off halfway through and turns into garbage, or the image editor program refuses to open the file claiming it is not supported. This behaviour is common across Lightroom, Photoshop, and the OS default Preview application (so it's not an Adobe problem).
However, I noticed that if I first copy the image file to my local hard drive, that copied file will open just fine. My hypothesis is that copying the file and editing it use AFP in slightly different ways (e.g. different block read size). Here's a file open from my FreeNAS's AFP share on the left, and the same file opened after being copied (using Finder) to my local drive:
If I unmount the AFP share and mount the same files over CIFS instead, the files all open perfectly in every application and no corruption is visible. So this problem seems specific to AFP.
My computer's operating system is Mac OS X Yosemite 10.10.3 (14D136). My ZPool's status is fine and the files are not actually corrupted on FreeNAS's disk:
freenas# zpool status pool: Primary-data state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. scan: scrub repaired 0 in 3h50m with 0 errors on Fri Jun 19 22:50:27 2015 config: NAME STATE READ WRITE CKSUM Primary-data ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gptid/40988749-8198-11e3-b6ae-d850e64929a5 ONLINE 0 0 0 gptid/40efa796-8198-11e3-b6ae-d850e64929a5 ONLINE 0 0 0 gptid/41423db8-8198-11e3-b6ae-d850e64929a5 ONLINE 0 0 0
I'm going to attempt to downgrade FreeNAS and retest.
EDIT: I rolled back to FreeNAS-126.96.36.199-RELEASE-x64 (2bbba09) and the problem went away, all images loaded fine over AFP in every application. I then rolled forwards to FreeNAS-9.3-STABLE-201506162331 again and the problem returned. So it's a new issue in 9.3.
#4 Updated by Nicholas Sherlock over 2 years ago
Hm that issue was with SMB and it worked correctly on AFP, the opposite of my problem. But it does have the same curious symptom that the files appear undamaged from the md5/sha1 sum on the file (I used Unix "md5" from macports), but my mac apps choke halfway through reading the file.
I wish I had something that could work out what those apps see when they look at the files.
#5 Updated by Jordan Hubbard over 2 years ago
- Status changed from Unscreened to Closed: Third party to resolve
Since we're just downstream consumers of netatalk, I think the best suggestion (really the only suggestion) here is to report this upstream to the netatalk folks and report that you're seeing corruption with version 3.1.7. We don't hack on (or have any familiarity with the internals of) netatalk so our chances of being able to fix it are zero, and we can't just roll back netatalk to the version it was in 188.8.131.52 because that would reintroduce a bunch of other bugs that have been fixed.
#6 Updated by Nicholas Sherlock over 1 year ago
I managed to track down this bug with the help of the NetATalk maintainer, and a fix will be merged there shortly:
This bug has the potential to corrupt files over AFP quite severely for programs which perform a read/modify/write cycle, as it causes an early EOF while reading a file.