Slow Login to SMB/AFP File Share

Question

smbizuser Author

Level 1

5 points

Slow Login to SMB/AFP File Share

Configuration:

OSX 10.11.3 (15D21)

Server V5.0.4

Services Running: Calendar, File Sharing, Profile Manager, Time Machine, VPN, Websites, Wiki, DNS, FTP, Open Directory

We have an issue that has been going on for several months where clients attempting to login to file sharing (AFP or SMB makes no difference) take excessively long to authenticate. It consistently takes about ~40-45 seconds to login or to even reject an incorrect password. The really strange part is that this affects every computer on our network except for one Mac Mini. It does not appear to be client specific, i.e. all users login with no delay on the one Mac Mini and slowly on every other computer. I haven't been able to determine any difference in network or connection settings on the different computers but I'm sure there are settings I'm not aware of.

Has anyone come across anything like this?

Thanks in advance.

Mac mini, OS X El Capitan (10.11.3)

Posted on Mar 3, 2016 5:32 PM

Reply

Answer 1

Mar 8, 2016 6:56 AM in response to smbizuser

Does the faster logging in Mac Mini have local home folders enabled? Or using a faster SMB protocol?

Reply

Answer 2

smbizuser Author

Level 1

5 points

Mar 8, 2016 5:36 PM in response to Bosco1983

Bosco,

All of the computers have local user accounts with their own local home folders though I'm not entirely sure if that is what you are referring to as having local home folders enabled.

I have tried to use the command "

smbutil statshares -a" to determine what version of smb the computers are running but I get the error message "smbutil: share name doesn't exist: No such file or directory". Is there another way to determine what protocol is being used?

Thanks

Reply

Answer 3

Mar 9, 2016 2:17 AM in response to smbizuser

I was just seeing if your home folders where networked or local, if networked then obviously there would be a login speed hit to connect to the share.

Your smbutil statshares -a command looks correct and works on my system. I am running this on the client rather than remotely via terminal if that helps?

Reply

Answer 4

smbizuser Author

Level 1

5 points

Mar 9, 2016 1:52 PM in response to smbizuser

Found the problem.

I checked the system.log on one of the slow client computers while logging in and saw this error message:

"acquire_kerberos failed user@OldServer.INT: -1765328228 - unable to reach any KDC in realm OldServer.INT, tried 7 KDCs"

It seems that all of the slow client computers were attempting to log in to an old, now defunct, server until it timed out and connected to the right server.

After doing some searching I discovered that all of the slower computers still had an old config file for an older version of Kerberos that pointed to the old server.

The offending file:

/Library/Preferences/edu.mit.Kerberos

I renamed this file and now file share logins are back to normal near practically instant speeds.

Reply

Answer 5

Mar 10, 2016 12:51 AM in response to smbizuser

Glad you got it sorted. Just checked my clients and that file doesn't exist. I assume that edu.mit.kerberos file mustve been from a previous OS? We are running 10.10 on our managed clients.

Reply

Answer 6

smbizuser Author

Level 1

5 points

Mar 15, 2016 10:32 AM in response to Bosco1983

Bosco,

I don't know for a fact that it came from a previous OS but while researching this problem I came across mentions of the Kerberos implementation changing with a new OS version somewhere along the line. So I am pretty sure that it is left over from an older OS.

Reply