Lion 10.7.2 Macs Unable to Login at LoginWindow (Works via console session)

[iamkmc]

Hey Guys,

I've been working on resolving this for the past couple of weeks but can't seem to narrow down what is causing this to reoccur.

This happens randomly with any of our 10.7.2 Macs currently in our production, and right off the imaging rack upon boot. At first I started digging through previous packages and DMGs that were deployed to SL 10.6.8 clients to see if they might be the cause, but it seems that there is more than one way to trigger this issue.

The only way I've managed to get back to a normal state was by performing an Archive and Install with a Lion 10.7.2 NetInstall image on our Netboot server.

Has anyone else ran into this or know what could be causing this occur? Local Admins, LDAP Users, and root are all unable to login at LoginWindow only via console. Let me know if you have any suggestions or resolutions I could attempt?

[tomt]

I've had the same result and it appears to be caused by a bad install package (Acrobat 9 in my case).

I have been able to consistently recreate the behavior but haven't found the root cause yet.

[iamkmc]

Yea, I assume that same thing also but I've been using my Mac since 10.7 and have run into this issue randomly as Apple released new stable builds. I would just come into work one day and not be able to login to my machine, so I reimaging would be the only way to get access to my Mac again.

Others have mentioned it's an issue with AD, but since Local accounts and root are unable to login either, I can't only point the finger a bad AD bind causing this much havoc.

[nortonpc]

For us it appears that any packages that write to /private cause this to happen. We did narrow it down to some legacy print drivers, Adobe products, and a webex client.

Recreating the packages fixed it in most cases. However with the Adobe Master's Collection, I converted to source, removed the files in /private and the rebuilt the dmg file.

[cam]

We saw this here today and were working with it too. It looks like if the '/private/var/audit/current' symlink is overwritten by a file, users may not be allowed to login. The symlink seems to be recreated on startup, so moving the bad file out of the way and rebooting allows users to login again.
Something like this in a startup policy is fixing it here:

mv /private/var/audit/current /private/var/audit/current.bak

Then add a 'Reboot Immediately' to the startup policy, so the Mac reboots and the symlink gets recreated. That seems to fix it (on 10.7.2); interested to hear if that works in other environments.

[tomt]

I just removed the /private folder from my Acrobat install package. It installed and did not break my 10.7.2 install. It looks like you guys have found the fix. Thanks guys!

[bhansen]

Thanks Cam! I removed /private/var/audit/current
from a misbehaving package and it now deploys properly.

[mclemens]

So after removing or renaming this /private/var/audit/current file is it fixed permanently or does this need to be run at every reboot?

[#9]

This worked for us too, I had to ssh into the box, then do

chmod u+w /var/audit/current

then

mv /var/audit/current /var/audit/current.old

then reboot

[mclemens]

Thanks a ton guys this works for us as well. We have been fighting with this issue for some time now. Apple's solution had been to reinstall the entire OS.

[mclemens]

Ok well it works.. but it comes back on its own randomly. Setting up a policy to check for and remove that file every 5.

[jwojda]

if it's coming back, then you have some package that was created on 10.6.x that included it and is probably being installed via policy. go through your current packages (if it's anything like ours, it's a very time consuming process) and ensure the file is removed from your original package, then you don't need the script.

I found it in several of our packages.. now that they are removed I haven't had an issue.

[taugust04]

Are these packages being built using the snapshotting features using Composer?

I routinely see the /private/var/audit directory modified when building packages. I always remove it from the given package I'm building and have never had a problem installing said package without that directory, and it's modified files, being included.

[Lincoln]

I was having this trouble too. I found going through all my packages individually tedious and it being summer holidays here I made use of a lab I had just imaged with only a base image. I had narrowed down the problem to 11 packages so I made a policy for each package and applied each policy to a seperate machine. Within 20 minutes I knew which package was causing the problem and was bale to fix it. Much quicker than opening each package individually and picking through its innards.

It was this thread which put me onto the solution to the problem, so thanks to all who contributed.

Regards

Lincoln