Network home folder clients (10.8.2) freezing

Awesome thanks!

mdutil -E / is what I used too, but didn't have any luck with it. I will try again using System Prefs just incase and let you know.

I had at least a minute or two before the computer would go down after reenabling spotlight.

On the affected user's computer:

1) Login to a local account and disable spotlight

2) Log off and login to the network account

3) Reenable spotlight and quickly drag everything (local hdd, network home directory, all network locations) to the privacy window

4) Remove everything from the privacy window

That aligns with what we saw here as well. Spotlight was continuously rebuilding on the affected user's account.

There's likely a bunch of workarounds effectively achieving the same result. I like the one you've come up with because it's easier than mine. Let us know if it holds out.

Hello to All of you, I have the same issue, I will disaible spotlight to see if it fixes on mine, one thing a been fighting with is reopening windows when logging back in on all network clients, do you guys have the same issue that reopens previous used windows when logging back in even when the check box is unchecked?, I am running Mac Mini Server and 2 iMacs as clients all running Mountain Lion 10.8.3, local users do not see this issue is only on network users, I would appreciate your comments. Thanks in advance.

By any chance does anyone having this problem also have Office for Mac installed on machines that any of these users utilize?

At our school, the teacher computers have access to Office for Mac, which in OS X seems to occassionally dump "Recovered Files #xxx" in their trash at shutdown/login.

We have had these issues with a few selected users at our school, all staff. After reading the above and noticing the same "indexing behavior" in the problem user's account, I tried to do some cleanup of their Network Home. Other than some old downloaded DMGs in their downloads folder, the only other thing I deleted was a "Recovered File #3" from the user's trash. I wasn't able to delete it either by way of the normal method, or by way of the Secure Delete method, I had to go into the Terminal on the server itself and manually "rm" the file out of the user's .Trash directory.

Prior to this, after login, if I checked the user's Spotlight in the menu bar of the screen, it would show a stalled progress bar for "Indexing" for several minutes and the session would freeze shortly after, no matter what I did. After deleting this directory, on next login, Spotlight had completed its work as soon as I clicked on the magnifying glass, and I proceeded to watch a video on Youtube while simultaneously creating and saving a Word Doc to the desktop without any slowdown.

I'm wondering if those recovered files are sometimes getting corrupted and then Spotlight is hanging on them when it tries to index them. If it helps at all, I know this particular user also like to modify some of her default Word templates and such, so perhaps that could explain further corruption in the Recovered Files they generate.

Hector, yes that check box doesn't work for us either. I haven't looked much into it.

strawberry_kurosaki, yes Office is on the affected computers. I haven't been able to confirm this is the source of the problem though.

We don't use Office (it's never been installed on these machines) and the problem runs rampant around here so I highly doubt it is the cause of the problem, although it may be an aggravator.

I also wanted to share this with you guys. I have been talking with Apple about this issue and if you can capture some spindumps while the problem is reproducing they will love you!

Here's Apple's instructions:

While the problem is ongoing (i.e. while you have Spotlight enabled and apps are spinning)

1 - Please make a note of which applications are spinning on the client when you experienced the problem. If more than one app is spinning, please note as many as you can.

2 -Please choose a subset of the spinning apps and take a spindump on them. Three or four apps would be enough.

i.e. something like: sudo spindump Safari

3 - Please take new 'mddiagnose' snapshots on BOTH client AND server while the problem is ongoing.

Please attach the list of spinning apps, spin dumps, and client and server mddiagnose to this bug.

4 - Please gather a 'sysdiagnose', taken while the problem is ongoing.

sudo sysdiagnose

Submit these files on http://bugreport.apple.com

Additional Info: here is exactly how this problem reproduces on our machines (I sent this to Apple), and how to actually capture spindumps on the frozen client machine. Hope this info helps you guys too.

Steps to trigger bug and gather data:

1. Reboot client machine, login to the affected network account on the client machine.

2. After logging in, wait for 1-2 minutes until all previously opened apps load and resume from the server, and then for the bug to trigger. (during this time I did not touch the keyboard or mouse.)

3. Bug did not seem to trigger, so logged out of the affected account, and then logged back in.

4. While logging in, during the 1-2 minute window (while apps are resuming), this time I used the keyboard and mouse to move around in the Finder and launch an app or two. (I believe this tends to exacerbate the problem)

5. The bug reproduced and the Finder began to spin first. After that, I switched to all of the other open applications clicking their open windows one-by-one causing them to start spinning almost immediately after they were clicked.

6. After all of the open windows began to spin, I fast-user-switched to the LocalAdmin account to take spindumps of them. Fast-user-switching also triggers the bug, so the *only way* I found to successfully fast-user-switch is to: (a) click the fast-user-switching icon in the main menu, (b) and choose "Local Administator" - which doesn't do anything for some reason, (c) then click the fast-user-switching icon in the main menu again, (d) and choose "Login Window". This is the *only way* to get out of the afflicted account. Doing this in ANY other way - will cause SystemUIServer to hang and you get trapped inside the network account.

7. I took spindumps of all the apps which I visually confirmed were spinning before fast-user-switching. All the spindumps I included are for spinning apps.

8. I took an msdiagnostic and sysdiagnostic on the server.

9. I took a msdiagnostic on the client, but msdiagnose hangs halfway through. I included the partial msdiagnostic file and the log from Terminal.

10. I also took a sysdiagnostic on the client, but it also hangs halfway through. I included the partial sysdiagnostic file and the log from the Terminal.

Hope this information helps. Ultimately, ~/.Spotlight-V100 seems to be causing the problems for us. Deleting it seems to temporarily solve the problem, but it will just come back. Disabling spotlight is the only 100% workaround.

I am having this issue with two seperate 10.7.5 servers in two offices, but they are both using 10.7.5 clients.

Some other details:

On the Server console an error is reliably produced at user login that says

"AppleFileServer: received message with invalid client_id".

At the same time the client console shows several errors including

"xpchelper: Could not get real path of user account home directory /Network/Servers/%HOMEPATH%"

"com.apple.coreservicesd: lsregister CFPreferences: user home directory at file://localhost/Network/Servers/%HOMEPATH% is unavailable. User domains will be volatile"

and "NetAuthSysAgent: AFP error -5019 mapped to EIO".

disabling spotlight via

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

as suggested by cafarom does indeed solve the crashing issue, but of course users are not happy operating without spotlight.

I've submitted this as bug report.

Has anyone received an update from Apple regarding this bug? It is occurring with increasing frequency on our network.

Obviously it's a serious issue because it can bring down someone's computer without an option to save existing work.

I may have found a work-around that does not involve disabling spotlight. At least it appears to be holding out relatively well on my machine.

You need to create a LoginHook to redirect ~/Library/Caches to /Library/Caches/username, as detailed by this post:

http://computing.geology.ucdavis.edu/security/lab/redirecting-cache.html

Make sure you set appropriate permissions on the LoginHook script and verify that it runs when you login by checking your console log.

I found a couple of errors in the posted script. Here is the script that I used: http://pastebin.com/rK22REBF