I've been rebuilding the index via:
mdutil -E /
which I understood would wipe and rebuild all spotlight indices, but maybe there is some sort of difference... I've done this on all clients, and on the server...
Are you rebuilding the index as the affected user, logged in to the server? I haven't been able to do this, because the users can only log in if spotlight is disabled, and if spotlight is disabled, then the spotlight prefpane doesn't work...
Perhaps I'm not understanding the order in which you are doing this... Could you clarify?
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
I just tried something which is working so far: I manually deleted the spotlight index (the ".Spotlight-V100" folder within a user's home folder) for an affected user. So far, the user's account is working normally.
This affected user also remembered something perhaps crucial: she said that prior to the problem, her spotlight index was always "rebuilding" (click on magnifying glass in menu bar, and "indexing" message and progress bar were visible). The problem first manifested after she performed a search while it was still indexing. If this is indeed the initating event, it may explain why it only affects some users...
I'll let you know what happens...
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.
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.
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
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.