AFP Users show as Disabled/Asleep

[benfeea1]

My Mac OS X 10.4.2 G5 Xserve connected to Active Directory is having AFP problems.

Users complain that they cannot connect to the server, or if they are connected already when they access the server they get the spinning beach ball.

When I check AFP in Server Admin it shows several of the clients as “Disabled/Asleep”. If I stop AFP and start it again all is well for a day or so.

I usually have about 10 to 20 clients connected at one time. They are mostly 10.3.9. I have the only 10.4.x client workstation. I have purposely kept it from connecting thinking it might be a spotlight thing. However, it still happens.

I have rebuilt the box but I still get the “Disabled/Asleep” problem.

I am running AFP, SMB, web, Extensis Portfolio Server 7.0.6, and Extensis Suitcase Server 11.0.4.

[anodyne]

We are seeing the same issue here. Active Directory bound servers w/ user home directories. I was hoping the 10.4.3 upgrade would be helpful .. unfortunately nothing has changed since upgrading. The problem can hit multiple times in the day. Sometimes disconnecting the “Disabled/Asleep” connections can get things going again, more often I need to stop/start service or reboot server to get things going. Not good at all …

[Anonymous]

We ran into this problem. We have a main xserver, which is our "Open Directory Master" authentication server, and a second xserver, which is our file server. The file server is set up as "Connected to a Directory System" using LDAPv3 and Directory Access. The authentication server is on a different subnet that the file server.

Example:

Authentication server ip: xxx.xxx.11.20
File server ip: xxx.xxx.10.10

The authentication server is additionally handling auto-mounting home directories via afp for network logins. There were no issues with the home directories or with connecting directly to a volume being shared via afp by the authentication server.

It was discovered that when the file server was placed on the same subnet as the authentication server the "Disabled/Asleep" problem went away. Users connected to the file server without any delays. Although this solved the problem, this was not an acceptable solution for us, and we needed the servers on separate subnets.

(Related side story that may help someone)
We had a previous problem with users who were logging in on client systems that were on a different subnet than the authentication server. They were unable to get their home directories auto-mounted across a subnet. This problem was solved by changing all references in the user’s open directory database entry (specifically the ""HomeDirectory"" field) from "afp://<machine name>.local" to the full domain name. Example: "afp://wigit.local" to "afp://wigit.foobar.com" I bring this up because it may be helpful to someone running into the above mention problem and have some bearing on this issue.

(Back on topic; Solution:)
The problem is with the default created NFSHomeDirectory path in the users open directory data. Under panther when the system creates a network home directory using the default NFSHomeDirectory you get a path similar to the following:

/private/Network/Servers/<machine>.<domain>.com/Volumes/<whatever>

This carries over to tiger during an upgrade. For some reason if you remove the "<machine>.<domain>.com" from the NFSHomeDirectory path of the user the "Disabled/Asleep" problem will go away for that user.

Under Tiger apple has changed the default NFSHomeDirectory path to:
/private/Network/Servers/<machine>/Volumes/<whatever>

So in a minor way, this may confirm that apple was aware that having the full domain in the path could cause a problem.

On the authentication server we changed the NFSHomeDirectory path information for all of our users and rebooted the authentication server. All users were able to login to the file server with out any problems, or delays.

So that’s the solution we came up with. At this point we are not sure why the "<machine>.<domain>.com" in the NFSHomeDirectory filed was causing problems for the file server on the other subnet. We came across the solution by chance, but did lots of testing to verify it was the problem, and removing the entry would solve the problem before we applied it to all our user accounts.

If you use this solution you will need to reboot all of your clients systems after the change and prior to users logging in. The NFSHomeDirectory path gets cached on the clients that auto-mount network home directories. Rebooting will clear it from the cache, other wise the client systems will look for network-mounted directories in the wrong location.

I hope this solution has some bearing on your problem.

[Anonymous]

I am having the same issue on my 10.4.3 server which is not connected to AD. I initally thought it might be a network issues, but we have eliminated that. I have recreated the issue with only one user connected as well as all of the users aside from that one, so I know it is not a particular client.

Has anyone successfully remedied this?

[benfeea1]

Well I thought 10.4.3 has fixed this problem.

Although the frequency of users showing up as “Disabled/Asleep” has gone down, it has not gone away.

I still get the problem about once a week.

[Anonymous]

Have you explored the “Disconnect Idle Users” settings. I am going to try that today.

Out of curiosity, do you have any devices hooked up to your Xserve (RAIDs, tape drives, SCSI cards)?

If this doesn’t work, I might be backing the server down to 10.3

[anodyne]

A little more regarding our situation:

As mentioned earlier, our users are in Active Directory. Our XServes are bound to AD, but our clients are not at this time. Servers running 10.4.3 and most clients are as well. We are hoping to bind all clients, but at this time it doesn’t appear that we have the support structure in place to manage all clients (numerous sites) successfully in an AD/Open Directory Master environment. Someday, but I digress …

When we initially observed this “Disabled/Asleep” AFP problem, we made some changes to the Profile/Home Folder path which seemed helpful (i.e. move toward using FQDN). This helped, but did not totally remove the issue. Given that we don’t have (most) clients currently bound to AD, we have since chosen to completely remove the home folder path for those users. Students use the “Connect to Server” method from a local user account, and specify their AD credentials to mount share/navigate to their home. What has seemed to help was changing the Authentication mode from “Any” to “Standard” … I’m not fond of this as it breaks AFP SSO. Changing to Kerberos doesn’t work at all .. I imagine that it’s expecting to be the KDC, not AD. I played around a little with Idle users w/out success. I will also note that this issue doesn’t plague all sites equally … some barely/ever see the issue while others are highly impacted.

Also, when we do observe this issue, a “top -o cpu” will reveal the AFP process at 90%/climbing. Sometimes trying to stop the AFP process via Server Admin will hang the machine (pingable, but not SSH/etc) and a physical reboot will be needed.

BTW, does anyone know what “AFP_Check” (or something very similar) is doing? I just noticed it as a running process last evening …..

[benfeea1]

A few more notes.
10.4.3 Server running on a Dual 2Ghz G5 XServe.
This server is only running AFP, SMB, and Web.
It is connected to an Active Directory Domain.
Most of the clients are also connected to AD.
Kerberous single sign on works.
It is not hosting home directories.
It has an XRAID connected to it.
It has a Fiber card and a video card.

I rebuild it from scratch just before Christmas.
I am getting the Disabled/Asleep problem again. teice in the last 24 hours.

[jimma]

I feel your pain, benfeea1 — I have the exact same configuration, and the exact same problem. (Are you hiding in my server room???)

I’ve pursued various theories, including:
– time synchronization … I’m not running NTP on the server, but I thought that the problem might have something to do the server & the clients not having the exact same time, so I found ways to make this happen.
– DNS — I made sure that not only the server, but every client, had forward and reverse DNS entries (in our Active Directory DNS — the OS X Server DNS service is disabled).

Nothing has worked … any suggestions would be greatly appreciated!

[benfeea1]

Yes jimma, I am hiding in the third rack on the right.

I have come up with a solution! It is an update called Mac OS X Server 10.3.9. It works great for AFP and SMB joined to an AD Domain. The only thing I loose is single sign-on (SSO) for AFP useres. However they don’t complain about that since the server actually stays up now.

Just make sure to follow Mike Bartosh’s excellent instructions for 10.3.x and AD.
http://www.oreillynet.com/pub/a/mac/2003/12/09/active_directory.html

#365095

[benfeea1]

delete

[Author]

Posts