3

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)?

Improve this question
5
  • 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
    Commented Aug 7, 2012 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
    Commented Aug 7, 2012 at 15:50
  • Are the machines all on the same subnet (e.g. 255.255.255.0) 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
    Commented Jul 11, 2013 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.
    Commented Dec 23, 2014 at 10:12
  • Additionally, where are you trying to connect to? Another Mac with Shareing enabled? A NAS with an AFP-Share?
    – J.C.
    Commented Dec 23, 2014 at 10:14

3 Answers 3

Reset to default
1

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:

 ~/Library/Preferences/.GlobalPreferences.plist

and

 ~/Library/Preferences/.GlobalPreferences.plist.lockfile

then reboot.

See the following link for more info:

http://derflounder.wordpress.com/2012/08/03/odd-afp-and-smb-connection-problem-caused-by-idisk-going-away/

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.

Improve this answer
5
  • 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
    Commented Aug 7, 2012 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
    Commented Aug 7, 2012 at 16:09
  • Fresh user account is able to connect instantly, we may have only looked to delete the contents of:
    – Si King
    Commented Aug 7, 2012 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
    Commented Aug 7, 2012 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
    Commented Aug 7, 2012 at 16:15
0

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

That fixed it for me.

Improve this answer
-3

use wireshark to view what traffic is being held up

Improve this answer
1
  • 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 ♦
    Commented Nov 29, 2012 at 6:01

You must log in to answer this question.

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