Process “has no account to back it” error in 10.5 server

[cam]

Since upgrading to 10.5 Server we have had recurring issues where authentication is not working, both for workgroup accounts and local accounts on the machine. Looking in the console I see the error “[process] has no account to back it!” that only a reboot seems to rectify. Has anyone seen this issue?

[nerkles]

I’m seeing the same thing, but have no idea of a cause or solution.

I even tried creating cron job to reboot at night, but once the problem starts, I guess “root” has no account to back it either, so it doesn’t reboot.

[baliset]

I also get this and it is crippling us. Various entries in the console logs list processes (“master”, “freshclam”, “ditto”) with “no account to back it” and our server freezes, normally overnight.

[jeffrey.c]

Did everyone who is experiencing this “upgrade” to 10.5.

Or is anyone suffering this after a clean install?

[baliset]

Our 10.5 installation was a clean install with user/group/computer lists imported from an export performed on the server’s 10.4 predecessor.

[cam]

We had the same install process: clean 10.5 install followed by importing our OD from our previous 10.4.11 install.

[baliset]

It’s worth mentioning that there is a specific pattern to the crashes that these errors seem to be causing. The console is especially full of these messages at times that launchd is attempting to run the daily housekeeping scripts the OS does at certain intervals. If you use Lingon (a launchd GUI) to peruse the list of tasks the OS runs you will see certain ones the OS performs “every 24 hours”. I got to wondering when those “every 24 hour” entries were actually running. Our crashes seemed to be happening between midnight and dawn. I used a shareware tool called “Onyx” which lets you manually trigger those housekeeping scripts that the OS would otherwise do itself daily, weekly or monthly (I’m presuming these are things like log rollovers, cache cleanups, etc). I ran Onyx at a certain time one afternoon. Since then, the server has frozen at exactly that time of day, and has sailed though the nights OK. I’m wondering if the “24 hour” counter was reset and these scripts are being triggered at a different time of day now. I’ll need to check if the console errors of the type we’ve been discussing are now peaking at the new time (as they are appearing at all times through the day but especially at the times I’ve mentioned) and post again.

[jeffrey.c]

Man, I was hoping you guys had NOT done a clean install, because then the answer would be easy.

😕

This is baffling.

Have you double-checked your export file that you already imported to make sure there were no accounts that could possibly conflict with system/standard accounts?

[jeffrey.c]

cam,

did you have any kind of similar event as bailset?

i.e. – manually running launchd jobs?

[baliset]

I doubt the imported accounts are to blame- we upgraded to Leopard server at Christmas and have had a generally good run. This problem has manifested more recently. Has there been a security patch in the last month or so? If so, we tend to apply it without delay.

[khiltd]

This sounds a little MacFixit-y, but have you verified permissions?

[baliset]

Yep. Permissions verified and Disk integrity checked.

[clearframe]

http://lists.apple.com/archives/macos-x-server/2008/May/msg00285.html

[Author]

Posts