I am having an issue for multiple (but not all) users whereby AFP connections are taking 4+ minutes to connect to the share. Some never connect. The spinning progress bar sits there but no auth window appears. So far I have:

  • Tested the network cable in a MBP which could connect instantly with correct credentials.
  • Power cycle
  • Ping AFP share - working
  • Ping server IP - working
  • Check DNS, added manually
  • PRAM reset
  • Tried connection over SMB and NFS, SMB would bring up the Auth window slightly faster but still a good 4 min wait
  • Created new local user account which was able to connect to the share instantly

Dumped network settings and location, which produced a strange result; with the AFP connection pending, ditching the Ethernet 2 interface in Network Settings brought about the connection. Upon ejecting the share and restarting the connection however, the same wait followed. Recreating the Ethernet 2 interface and dumping it again brings about the connection.

Pulling the cable out (with Airport off) brings up the authentication window instantly.

We have restarted the AFP server and all switches.

We have swapped out the Cat5e cabling between the AFP server and the switches.

It appears that all the machines are on 10.7.4.

I have read some posts on Google about NetAuthAgent maxing out CPU cycles, I am going to test the offending machines for that now.

How can I fix an issue with AFP where some users connect after 4 minutes and others never connect (spinning progress bar and no authentication dialog)?

  • What credentials are being used to attempt to log in (ie OD, AD, local users only, some mix)? Are all connections being made to the same address, and if so what is it? Do all clients have the same DHCP, DNS info etc? Based on your OP I think this is a software issue instead of hardware. – da4 Aug 7 '12 at 14:45
  • Hi, all users are using OD credentials, connections are to different boxes in different locations on separate address ranges. All clients use DHCP and are on the same address range. We have 650 users with around 10 reporting this issue – Si King Aug 7 '12 at 15:50
  • Are the machines all on the same subnet (e.g. if they are all set via DHCP then this should not be an issue but I commonly see AFP shares take a very long time if the subnet is misconfigured. – hoss Jul 11 '13 at 15:50
  • Could you look into the Console (/Applications/Utilities/Console.app)? There are probably some entires there which would be useful in identifying the problem. Please post the entries. – J.C. Dec 23 '14 at 10:12
  • Additionally, where are you trying to connect to? Another Mac with Shareing enabled? A NAS with an AFP-Share? – J.C. Dec 23 '14 at 10:14

Yup, we saw the same exact symptoms, only on 10.7.4 machines, and after some digging, it appears to be a preference file causing this behavior.

Backup then delete the following:




then reboot.

See the following link for more info:


If you delete the files above you'll have to redo your Mouse preferences, and perhaps something else, from scratch, but it was no biggie as far as I could tell.

  • Thanks, should have mentioned, tried the advice from that link as well, no joy, also dumped the whole prefs folder, with no joy. No spikes in the system processes either, going for the 10.7.4 combo update at 17:30 on one of the Macs, if no fix will then update to 10.8 to see if that helps. Not all my users can update to 10.8 however to that won't be a fix really... – Si King Aug 7 '12 at 16:09
  • What happens if you create a fresh account or use the Guest account on the same machine? By the way, upgrading to 10.8 did fix it for us, too. But this is lame of Apple – Lurch99 Aug 7 '12 at 16:09
  • Fresh user account is able to connect instantly, we may have only looked to delete the contents of: – Si King Aug 7 '12 at 16:11
  • .GlobalPreferences.plist, not the entire list as it is hidden I think we only deleted the contents of the prefs folder so we are going to double check that first... – Si King Aug 7 '12 at 16:12
  • Try moving the entire ~/Library/Preferences folder elsewhere, and force it be recreated. Reboot. I'm not 100% sure it is only those two files -- this solution has worked on some of our 10.7.4 machines but not all. Moving the ~/Library/Preferences folder has, however, worked on all. – Lurch99 Aug 7 '12 at 16:15

If the users have had MobileMe accounts active, go to system pre and the MobileMe tab and log out.

That fixed it for me.


use wireshark to view what traffic is being held up

  • 2
    Can you give some more details on how this would work? For a user unused to Wireshark a simple "use this" is probably not enough. – nohillside Nov 29 '12 at 6:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .