Currently Being ModeratedMay 23, 2011 8:45 AM (in response to DaiVernon)
I've seen this behaviour on my network. 99% of the time, a restart of the client computer fixes it.
.9%, there's another network user logged into that computer already. ....and that user has not logged out... They've just returned to the login window.
Lastly .1%, a restart of the AFP service on the server would fix it.
Between these three reasons, I've been able to rectify the situation in every time.
Currently Being ModeratedMay 23, 2011 8:57 AM (in response to gracoat)
Thanks for your interest...
this occurred over the weekend so I was unable to fully document the situation...
but restart didn't seem to clear it, I asked colleague to demo this to me and the error still occurred...
the 0.1% solution has yet to be tried....
Currently Being ModeratedMay 23, 2011 1:10 PM (in response to DaiVernon)
Stopped and restarted AFP service...same result, unfortunately...
We are set up as mobile users
2 specific macs on which my colleague could not log in.
1 on which I could not log in
In each instance, neither of us had used these macs before so were not listed in logon screen - had to use <Other> and enter credentials manually. Proper credentials entered, icons for each individual displayed, but still <unable ...an error has occurred>
Currently Being ModeratedMay 23, 2011 1:18 PM (in response to DaiVernon)
I had this same issue recently, and the root of the problem was that our directory server was not replicating properly. If you have a master/replica configuration, I would try destroying the replica and re-binding.
Currently Being ModeratedDec 13, 2012 8:53 AM (in response to DaiVernon)
We just had a similar issue here.
On the MacBook Pro, we needed a new user to log in. Existing MBP users were fine, new users no chance, although administrator accounts were OK. OSX 10.7.4, same issue with 10.7.5.
Clues were found elsewhere on this site (https://discussions.apple.com/thread/4140320?start=0&tstart=0), but what we did to fix it was this:-
Ensure the Mac will create a local folder for new user accounts (top tick-box)
In AD, turn off the Z: drive mapping to the home folder (or whatever drive you use) for that particular user
On the Mac, log in and let it create the local home folder
In AD, turn the drive mapping back on and respecify the home folder path
The account should now continue to work as it's already created the local home folder.
Admin accounts worked because we don't map the home folder for those. Originally we were mapping using a logon script, which is why we didn't have an issue when setting up the other users initially. What probably doesn't help is that we use DFS, and the Macs don't like talking to DFS (we have to map to the \\servername\share instead of \\domainname\dfs-share for those).
Hope this helps. Many thanks to user "Think Touch" for providing the clues.