PDA

View Full Version : AFP unstable since upgrade to Leopard, 10.5.2 no help, HELP ME!




alarcon
Feb 19, 2008, 03:35 PM
I had a disaster on my xServe when I upgraded to Leopard.
AppleCare helped me get it up and running, but there is still a glitch with AFP.
Every couple of days I have to restart AFP because it stops working...clients can't log-in to their Network Home Directories.

Any body having the same issues. I called AppleCare and they said wait for the next update, but I can't wait that long.

Any help or suggestions would be helpful. THANKS!



Les Kern
Feb 19, 2008, 07:23 PM
Perhaps write a cron job to stop/restart the service every day or however often you need it? Beyond my expertise, but that seems like a reasonable solution you can do or have done by someone who knows how?

BWhaler
Feb 19, 2008, 11:42 PM
Leopard server is simply not ready for a commercial environment.

I thought 10.5.2 would get Leopard server to the minimum quality levels as it did with the client, but alas it is not true.

AFP is the worst of the bugs. How that did not get fixed is beyond me. Either way, I would hold off with Leopard server if you can. Otherwise, you're going to need to work around this bug every day.

svalenti
Feb 20, 2008, 06:51 PM
If your clients are Leopard, connect with SMB.

I'm having the same problem. I've followed all the advice and work arounds I could find online and the only one that has worked for me is connecting with SMB.

MacsRgr8
Feb 22, 2008, 04:23 PM
I have heard lots and lots about Leopard Server's AFP issue combined with Open Directory.

Mostly it seems OD crashes after a couple of AFP client logins, and I have heard some workarounds (like making a cron job to reboot AFP service every now and then) may work, but not for everyone. Sometimes only a complete reboot of the server will work...
OTOH I have also heard may times of similar setups NEVER crashing...

So, not everyone has this issue, but lots do... So WTH is the cause..? It can be a lot of things that I can think of, off the top of my head...:
- DNS issues (therefore OD issues resulting in AFP crash)
- Kerberos issue
- OD binding issue with client
- AFP client issue
- Bonjour opposed to FQDN issue...?

Somehow in a "controlled environment" (small physical Gb switched network, 24 bits network, Leopard Server being DNS, OD, AFP server, a couple of Leopard clients) it all seems to work great.

What I am trying to say, is that in principle 10.5.2 Server / 10.5.2 Client does work to its full potential, but in some environments the mentioned issue does occur too much.
Maybe many system admins use the same installation procedure which worked fine under Panther and / or Tiger services, but somehow something goes wrong in Leopard...?
Has anyone tried (dare I mention this..) installing the same Leopard Server, but this time using two of the other three setup wizards? I.e. NOT using the "advanced mode"?
This is just purely to find out if the Leopard Server with OD always crashes on that network, or if a different config can help solve the issue...?

dr_lha
Feb 26, 2008, 09:50 AM
I'm having the same issues with our XServe, which our sysadmin upgrade to Leopard on the advice of some Apple tech guys who visited our University. All I can say is that I'm glad we do all our remote mounts via NFS. The only reason I used AFP is for TimeMachine and I'm finding that I have to restart the AFP service on our XServe every day because of the hang ups. Its practically useless.

brian20
Feb 27, 2008, 12:51 PM
I'm having a similar issue with one aberration. Typically the server won't let some or all of the users log back on afterwords. The really strange part is that it let's some users on and others not. Has anyone else seen this?

bb

garydailey
Mar 4, 2008, 10:02 PM
I had a disaster on my xServe when I upgraded... I have to restart AFP because it stops working...clients can't log-in to their Network Home Directories.

There is an 'easy workaround' that does not kill everyone.
(the one after the bad suggestion by Apple).

Apple will suggest running a terminal command
sudo killall -HUP AppleFileServer

But it doesn't work!

I found on my 4 client setups (yes, I jumped in way too early, and now four companies with over half a million in Macs, are now regretting it), that running the killall will allow the user to reconnect, but most of the time, they can't see their shares. If the killall worked, I was going to do a shell script and crontab it to run every 5 minutes. But oh well, it was another trojan horse, not unlike Leopard Server to date.

What does work, is simply to open server admin, then toggle the "connect.." from 'any method' to 'standard. Hit save, then toggle back to 'any method'. Voila, everyone can reconnect and no one is disconnected in the process.

If anyone has an idea how to automate the change, or what it actually does (kill the cache?), then let me know. It would be a perfect fix for a horrible Apple oversite.

(now on my soapbox). I cannot even imagine how even the smallest software company (and Apple is NOT small) could ship a Server product that can't even handle the simpliest vanilla Server installation of its own product. I can only hope the product manager of server gets canned over this one. I have installations of 3, 8, 20 and 40 Macs. NONE of them can reliably disconnect and reconnect on binded AFP systems.

To make matters worse, Apple suggested to me, that I should get the $19k support package for my clients to get their custom workarounds. YES, they want me to pay for the bug fixes. I'm guessing that we'll be waiting a VERY long time for the fixes to be integrated.

Gary Dailey
Mac Guy

garydailey
Mar 4, 2008, 10:08 PM
I have heard lots and lots about Leopard Server's AFP issue combined with Open Directory... Somehow in a "controlled environment" (small physical Gb switched network, 24 bits network, Leopard Server being DNS, OD, AFP server, a couple of Leopard clients) it all seems to work great.

Nope, We have tested, and brought in two other Mac OS X Server Admins to do very straight forward, wizard installs. Bind the Macs. Just enable, the basics. Then take anyone, connect, disconnect, connect. After 3-10, it will fail . It seems to have its biggest issues in the 5-8 and up user range.

mahurangi
May 11, 2008, 10:41 PM
We call this the period 2 bug because when 3 or 4 classes log on at period 2, this bug arises-but not when 1 or 2 classes login earlier or later. Most have logged on and the stragglers can not log on. we tell everyone to leave the keyboards alone and restart the server. This fixes the login issue and the existing users can continue working without losing connection with the server which is great. stopping and restarting afp seems to kill all the students connections to the server and they lose all their work and have to log back in. which I accidentally did. when I use a script from curmis blog
http://curmi.com/blog/2008/04/08/leopard-server-and-directoryservice-crashes/
What is it about the restart of the server that is different from restarting afp
I am sure the problem has arisen due to kerberos not running properly on my server and probably others. I am going to use the idea above and switch the afp login in the "connect.." from 'any method' to 'standard' and see what happens tomorrow period 2
Apple must fix this!!!! or if it is a kerberos issue, explain how to kerberize the directory service when every other part of the server is working fine.
Maybe it could also be that the second server with the web and mail server on it is still running 10.4.11
Any thoughts would be helpful

MacsRgr8
May 13, 2008, 02:10 PM
Few follow-ups...

I also can generate the issue...
As you all probably know, it is the OD that crashes (caused by AFP authentications), and the AFP server then cannot connect to the re-spawned OD server.
Restarting the machine helps of course, and simply restarting AFP service (either by Server Admin GUI , or via CLI) sometimes helps.
I did find out that relaunching the .com.apple.AppleFileServer.plist in /System/Library/LaunchDaemons/ helped all the time though.

I have heard that the 10.5.3 Server betas seed to fix this issue... no joking! ;)

dr_lha
May 13, 2008, 03:19 PM
If so 10.5.3 can't be released soon enough! Although our Server chugs along fine with NFS mounts, AFP is useless. Luckily I persuaded our sysadmin that as we have mixed Mac/Linux clients, that we should stick to NFS for all of them, otherwise we'd be basically out of action using AFP.

This is all a bit embarassing for Apple I think, who are trying to push Leopard as a Server OS. The inability to actually serve files seems to be a major bug, and I can't believe they've waited this long to fix it. Sometimes Apple sucks.

MacsRgr8
May 13, 2008, 03:35 PM
This is all a bit embarassing for Apple I think, who are trying to push Leopard as a Server OS. The inability to actually serve files seems to be a major bug, and I can't believe they've waited this long to fix it. Sometimes Apple sucks.

Well, it seems this AFP - OD bug has seriously been so major that the team has been working 24/7 on it in Cupertino...
I have heard that they have asked all log files related to this issue from developers... can you imagine the work examining all those log files...
Remember this issue doesn't occur all the time. Presumably Apple had a tough time to see this bug happen in their own labs.
But, IMHO the iPhone was in the way of Apple actually finalising Leopard Server...

rezenclowd3
May 28, 2008, 01:05 PM
Does the new 10.5.3 fix the AFP/ Open Directory issue? I need to rollout our Xserve which will host AFP shares...

MacsRgr8
May 28, 2008, 01:08 PM
FYI.. the 10.5.3 client has been released, but my 10.5.2 server doesn't show any 10.5.3 server update yet...

rezenclowd3
May 28, 2008, 06:03 PM
Ah, I should have read more of the news. Ill wait to hear about a 10.5.3 server update.

MacsRgr8
May 30, 2008, 06:08 AM
You can download it now via Software Update.

It is the same build number as the client: 9D34

dr_lha
May 30, 2008, 10:19 AM
You can download it now via Software Update.

It is the same build number as the client: 9D34
So does 10.5.3 fix the issue? I haven't updated our server yet because our IT guy is on vacation.