Project

General

Profile

Bug #10284

From Mac OS, files appear corrupt over AFP share, but fine on CIFS share

Added by Nicholas Sherlock about 2 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Critical
Assignee:
Category:
Services
Start date:
06/19/2015
Due date:
% Done:

0%

Hardware Configuration:
Blanket Approval:
No
ChangeLog Required:
No
Needs QA:
Yes
QA Status:
Not Tested

Description

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-9.2.1.9-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.


Related issues

Copied to FreeNAS - Bug #15422: From Mac OS, files appear corrupt over AFP share, but fine on CIFS share Ready For Release 06/19/2015

Associated revisions

Revision 0e42112d
Added by Josh Paetzel about 1 year ago

Fix a file corruption bug in netatalk3

Ticket: #10284

This is a huge shout out to Nicholas Sherlock
who really drove getting this fixed upstream.
Due to the severity of the issue I grabbed
the patch and put it in to FreeNAS rather than
wait for the fix to trickle down.

History

#1 Updated by Nicholas Sherlock about 2 years ago

  • Description updated (diff)

#2 Updated by Nicholas Sherlock about 2 years ago

  • Description updated (diff)

#3 Updated by John Hixson about 2 years ago

Could this be related to #9123 ?

#4 Updated by Nicholas Sherlock about 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 about 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 9.2.1.9 because that would reintroduce a bunch of other bugs that have been fixed.

#6 Updated by Nicholas Sherlock about 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:

https://sourceforge.net/p/netatalk/mailman/netatalk-admins/thread/CADwwazbRCufbU2PWVTmeXCeaMrQ-ve7oKyFy5b5uJxB7fKxLcA%40mail.gmail.com/#msg35084885

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.

#7 Updated by Josh Paetzel about 1 year ago

  • Assignee changed from Suraj Ravichandran to Josh Paetzel
  • Target version set to 261
  • Priority changed from No priority to Critical
  • Status changed from Closed: Third party to resolve to Fix In Progress

I'm going to go ahead and merge this patch in to FreeNAS.

#8 Updated by Josh Paetzel about 1 year ago

  • Status changed from Fix In Progress to Ready For Release

#9 Updated by Josh Paetzel about 1 year ago

  • Copied to Bug #15422: From Mac OS, files appear corrupt over AFP share, but fine on CIFS share added

#11 Updated by Jordan Hubbard about 1 year ago

I recommend also creating another bug to update netatalk and make special note to back this patch out again if and when it is subsumed by an upstream release.

#12 Updated by Vaibhav Chauhan about 1 year ago

  • Target version changed from 261 to 9.10-STABLE-201605240427

#13 Updated by Vaibhav Chauhan about 1 year ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF