Skip navigation
This discussion is archived

OSX 10.6.4 Random AFP Crashes 2 -3 times a week

13130 Views 27 Replies Latest reply: Oct 26, 2010 5:17 PM by kyleh0000 RSS
  • pcolvin15 Level 1 Level 1 (90 points)
    Currently Being Moderated
    Sep 7, 2010 8:39 AM (in response to kyleh0000)
    I have two mac-mini's running SNL 10.4.6, with 4G of RAM. One is set up as the OD master, and with DHCP, DNS, print service, Web, and WINS. AFP and SMB are active for it's own shares. The other is set up as an OD replica and runs AFP, iCal, iChat, Mail, SMB, SUS, and is the Web/Wiki master. It supplies the file services using a DroboPro under iSCSI w/4TB of disk space. We used to use a LaCie 4Quad, but found that the firewire interface would quickly become I/O bound and cause us to sustain a number of volume directory crunches and side issues until we moved to the Drobo (such as you can't mount it in single user, can't run Disk Warrior on it is safe mode, etc.).

    I've never had an AFP crash, and I've been up since October, and have never heard of the AFP/OD bug you mentioned. I only support 7 users and support a small amount of streaming video to local clients. My clients are a mix of iMac, MBPs, a couple of Dell PC's w/XP, and a Win2K3 server set as a standalone. My clients also run Parallels 5 and XP.

    I support outside VPN through Equinux VPNTracker, iPhone access, and site-to-site VPN connectivity using SonicWall TZs.

    The largest issue I've hit has been repeated LDAP corruption, which has me taking to destroy and rebuild it every so often (or when my diradmin suddently can't log in).
    MBP17, Mac OS X (10.6.4)
  • Bruiza Calculating status...
    Currently Being Moderated
    Sep 19, 2010 6:32 PM (in response to kyleh0000)
    +1 on AFP problems in 10.6.4

    We have a client with a recently installed mac mini server running 10.6.4.
    The AFP service has choked a number of times preventing users accessing file shares. ~5 users on the network. Solution is to stop and start the service and all is fine again but it is a pain.

    MacBook Pro, Mac OS X (10.5.8)
  • pcolvin15 Level 1 Level 1 (90 points)
    Currently Being Moderated
    Sep 19, 2010 9:14 PM (in response to Bruiza)

    Have you shut off spotlight as noted above? Also, are you running time machine? There are numerous posts about time machine on top of spotlight will cause afp to crash. Restarting afp clears the contentions, but usually only for a short time.
    MBP17, Mac OS X (10.6.4)
  • Lee Howard1 Level 1 Level 1 (65 points)
    Currently Being Moderated
    Sep 23, 2010 5:06 AM (in response to kyleh0000)

    Were in the same boat. Randomly afp connections will multiple out of control, hitting anywhere between 3000 to 7000 connections!

    I've disabled spotlight on all shares and volumes, repaired prefs etc. But still the same

    This only started after the 10.6.4 update. Never had any problems with 10.6.2. We skipped 10.6.3 after reading a few stories on here.

    Is there an easy roll back method?
    MacBook Pro 2.53GHz 4GB ram, Mac OS X (10.6.4), 3 x Xserve's,Xraid, Promise Raid 250+ clients
  • Lee Howard1 Level 1 Level 1 (65 points)
    Currently Being Moderated
    Oct 1, 2010 12:43 PM (in response to kyleh0000)
    Hi All

    I've open a case with Apple regarding this fault. They have all my logs and have asked a number of questions about me using both ethernet ports?

    I'll update when I hear back from them.

    MacBook Pro 2.0GHz 1.5GB ram, Mac OS X (10.5.2), 3 x Xserve's,Xraid, Promise Raid 250+ clients
  • Ben Pirozzolo Level 2 Level 2 (165 points)
    Currently Being Moderated
    Oct 7, 2010 6:36 AM (in response to kyleh0000)
    Hello all.

    I can only report that i am having the same problem.

    However can i assume that everybody who is having this problem has binded ethernet ports? I have our 2 onboard XServe Ethernet ports binded to one virtual connection. This has caused many a strange problem in the past, i'm guessing this is another.
    Mac OS X (10.6.4)
  • Lee Howard1 Level 1 Level 1 (65 points)

    Apple have confirmed there is a bug in 10.6.4 which is causing these AFP crashes.
    However they could not suggest a work around or confirm it would be fixed in 10.6.5
    Best ETA for 10.6.5 was within the next 6 months.

    Our server doesn't use binded ethernet ports, so I don't think that is related.

    This weekend we've rolled our server back to 10.6.1. This version has previously run for over a year without even a reboot. So I'll see how it goes this week...

    MacBook Pro 2.0GHz 1.5GB ram, Mac OS X (10.6.4), 3 x Xserve's,Xraid, Promise Raid 250+ clients
  • Jackoncept Calculating status...
    Currently Being Moderated
    Oct 21, 2010 8:22 AM (in response to Lee Howard1)
    I am experiencing the same issue to a customers MacMini Server. Except the rollback to 10.6.3, does anyone of you find any other workaround ?

    Config : 10.6.4 MacMini, only services : AFP and OD…
    MacBook Pro, Mac OS X (10.6.1)
  • Lee Howard1 Level 1 Level 1 (65 points)
    Currently Being Moderated
    Oct 22, 2010 1:13 AM (in response to Jackoncept)

    Our rollback to 10.6.1 worked for 10 days and then the fault reappeared

    It looks like to me that the afp 'bug' is also in 10.6.4 client. And its the client machines causing the server to trip up. They seem to loose AFP connection and auto reconnect, creating hundreds of ghost connections on the server per user

    See here

    He's running a 10.5 server with 10.6 clients and getting the same thing. So surely this points to the client OS

    We've only had this problem after updating the server and clients to 10.6.4.

    So my options are rollback all the clients to 10.6.1 which I know previously ran for a year, or wait until and hope 10.6.5 will fix the issue

    My guess is that 10.6.5 will be out within the next 90 days as it will integrate with the OS X App Store announced on Wednesday


    MacBook Pro 2.53GHz 4GB ram, Mac OS X (10.6.4), 3 x Xserve's,Xraid, Promise Raid 250+ clients
  • Vern Dempster Level 1 Level 1 (20 points)
    Currently Being Moderated
    Oct 26, 2010 5:03 PM (in response to Lee Howard1)
    Hi all
    Great to see another discussion on this issue. I had contributed to "10.6.3 frequent crashes" but I get an error when I link to it (strange) so I discovered this discussion which is my situation since May at my school. Xserve with 200-300 connections usually. Issues started with 10.6.3 (10.6.2 worked fine). Crashes 3 or 4 times a day 1000s of duplicated Ghost connections. After 3 or 4 weeks Coped by turning off timeMachine and not using any programs on the server(as discussed on the previous discusssion). Reasonably stable but one particular period of the school day would consistently cause the issue.

    Tried Apple - sympathetic but no assistance. Rolled back to 10.6.2, fresh install of 10.6.2 10.6.4 etc - problem still there today. Using time machine to recover a file crashed afp immediately - (I run time machine manually outside of school time occasionally to back up students docs.)- Using server admin on server crashes afp within an hour or 2.

    Today was a new thing. I inserted a DVD to copy it into a share and afp died within 10 secs of insertion.- no one could login!- no shares available. Shows quite clearly on the logs. I also notice that iphoto 09 is incredibly heavy on afp usage.

    I had not thought of 10.6.4 clients adding to the problem. I have about 10 that are upgraded from 10.6.2. Maybe that does add to the problem. 50% of our machines are 10.5.8. maybe that doesnt help either.
    xserve 2.26 quad, Mac OS X (10.6.4)
1 2 Previous Next


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.