Bug #3292

Errors with Apple File Protocol

Added by Tim Grantham over 1 year ago. Updated 7 days ago.

Status:ClosedStart date:10/11/2013
Priority:Nice to haveDue date:
Assignee:Josh Paetzel% Done:

0%

Category:-
Target version:9.2.0-RELEASE
Seen in:9.1.1-RELEASE

Description

When accessing a freeNAS share from either MacOS X 10.8 or 10.9, the following error is repeated constantly in the logs of the OS X machine

10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2
10/11/13 9:32:41.000 AM kernel0: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2

History

#1 Updated by Emory L. over 1 year ago

I can replicate this condition with both of the aforementioned releases of OS X:

Oct 14 20:56:21 workstationname kernel[0]: AFP_VFS afpfs_vnop_getxattr:  bad dataLength offset 2 replySize 2
Oct 14 20:56:21 workstationname kernel[0]: AFP_VFS afpfs_vnop_getxattr:  bad dataLength offset 2 replySize 2
Oct 14 20:56:51 workstationname kernel[0]: AFP_VFS afpfs_vnop_getxattr:  bad dataLength offset 2 replySize 2
Oct 14 20:57:22 workstationname kernel[0]: AFP_VFS afpfs_vnop_getxattr:  bad dataLength offset 2 replySize 2

#2 Updated by Jordan Hubbard over 1 year ago

  • Status changed from Unscreened to Screened
  • Assignee set to Josh Paetzel
  • Target version changed from 48 to 19

BRB: We just upgraded to netatalk 3, which may fix this issue. Is it possible for you to try one of the FreeNAS nightlies to see if this is true? http://sourceforge.net/projects/freenas/files/FreeNAS-nightlies/2013-10-09/ contains the relevant bits. Thanks!

#3 Updated by Stephen Burnside over 1 year ago

Yes, the 9.2 alpha above with Netatalk 3.0.5 installed does fix this issue. It also fixes a very annoying Finder "-36" error on Mac OS 10.5 ppc when attempting to open a file saved by Safari or FireFox/TenFourFox to a shared network Downloads folder. (not present on 10.6+) Read/write speeds also seem increased on lz compressed datasets as measured by QuickBench, read speeds saturate gigabit ethernet and write nearly so on a low end Core2 1.8 GHz server. Thanks for updating netatalk.

#4 Updated by Jordan Hubbard over 1 year ago

  • Target version changed from 19 to 59

#5 Updated by Jordan Hubbard over 1 year ago

  • Status changed from Screened to Resolved

Marking as resolved.

#6 Updated by Craig Rodrigues over 1 year ago

  • Status changed from Resolved to Closed

Fix confirmed by Stephen Burnside in 9.2.0-ALPHA.

#7 Updated by Martin Machacek about 1 year ago

Craig Rodrigues wrote:

Fix confirmed by Stephen Burnside in 9.2.0-ALPHA.

I'm still seeing this problem on FreeNAS-9.2.1.3-RELEASE-x64 (dc0c46b) when accessing AFP share from OSX 10.9.2. It may be caused by absence of the .AppleDB directory in the root of the share (which is a problem by itself).

#8 Updated by Jordan Hubbard 7 days ago

  • Target version changed from 59 to 9.2.0-RELEASE

Also available in: Atom PDF