Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

AFP unstable since upgrade to Leopard, 10.5.2 no help, HELP ME!

A

alarcon

macrumors newbie
Original poster
Feb 6, 2008
2
0
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!
 
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?
 
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.
 
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.
 
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...?
 
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.
 
Afp

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
 
Re: AFP unstable since upgrade to Leopard, 10.5.2 no help, HELP ME!

alarcon said:
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.
Click to expand...

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
 
Re: AFP unstable since upgrade to Leopard, 10.5.2 no help, HELP ME!

MacsRgr8 said:
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.
Click to expand...

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.
 
re AFP unstable since upgrade to Leopard, 10.5.2 no help, HELP ME! Reply to Thread

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
 
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! ;)
 
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.
 
dr_lha said:
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.
Click to expand...

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...
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back