Once in a while (3 times over the past four weeks), I don't exist. The message in the title of this question is my response when I try to run ssh while not existing. Also, when I don't exist, if I run id, it shows my uid and not my username as it otherwise does. And I can't use sudo:

; sudo date
sudo: unknown uid: 13799

Every time, the problem disappears spontaneously within the hour, and I exist once more. Fortunately, I always have a terminal window with a root shell in it around, so I can still poke around in the system. And I see nothing amiss, at least nothing I can make sense of, except perhaps these lines in /var/log/opendirectoryd.log:

2012-02-27 07:31:39.911 CET - 70535.351417.351419.351421 - Client: netstat, UID: 0, EUID: 0, GID: 0, EGID: 0
2012-02-27 07:31:39.911 CET - 70535.351417.351419.351421, Node: /Local/Default, Module: PlistFile - recordtype 'networks' attribute 'address' is not indexed: performance hit
2012-02-27 07:31:40.904 CET - 70539.351444.351448 - Client: launchd, UID: 13799, EUID: 13799, GID: 20, EGID: 20
2012-02-27 07:31:40.904 CET - 70539.351444.351448, Module: SystemCache - unable to find node 71E63E19-F41E-4AF3-89A0-F50FE5185E5B
2012-02-27 07:31:40.905 CET - 70539.351444.351448 - Client: launchd, UID: 13799, EUID: 13799, GID: 20, EGID: 20
2012-02-27 07:31:40.905 CET - 70539.351444.351448, Module: SystemCache - ODQueryCreateWithNode failed with error 'Node ID is invalid' (90001)

Those are from this morning, as I woke up the laptop (I have used odutil to raise the logging level a bit). I've been poking around with dscl, and everything seems normal – I can see all data on my own user – but I am not very familiar with directory services, so I may well have missed something. (How do I lookup myself by uid using dscl?)

So my question is twofold: Does this problem ring a bell? My google-fu is not up to finding anything relevant. And can you suggest things to try to get a further handle on the problem, tests to run, things to look for?

While I have been typing in this question, today's event ended, and I exist once more. So it may well be a week or more before my next chance to debug this. I'm on OS X 10.7.3, btw, on a MacBook Pro.

  • Did you install Lion Server on your MacBook Pro, and do you run Open Directory? Is your MacBook Pro joined to an Open Directory server at your workplace or elsewhere? Feb 27, 2012 at 7:29
  • @JasonSalaz: No, it's plain Lion, nothing fancy, standard setup. It runs opendirectoryd locally, but that is the default setup I believe, inherited from a sequence of machines using Migration Assistant, all the way back to Tiger, if memory serves (which it might not – I may have started from scratch during a migration years ago). Feb 27, 2012 at 8:12
  • apple.stackexchange.com/questions/43940/… is very similar thread to this one.
    – mspasov
    May 11, 2012 at 10:10
  • @mspasov: Thanks for the pointer! I'll try the fix mentioned there next time it happens to me, as I am sure it will. May 12, 2012 at 19:34

1 Answer 1


This does indeed ring a bell, as I've seen similar issues on a variety of systems ranging from 10.3 through 10.6. Here are some of the causes I've observed, in no particular order.

  • Incorrect DNS server addresses in the network configuration
  • Incorrect LDAP server or server aliases (if the machine is part of an LDAP or OpenDirectory network)
  • Faulty PAM modules (if you have installed third-party software which uses PAM or installs into /etc/pam.d)
  • Mixing Local/BSD accounts with LDAP/OpenDirectory accounts. This can happen if you have accounts which have been repeated migrated across many versions.
  • Account GUIDs becoming out-of-sync due to migration or other corruption of the OpenDirectory database.
  • Note that it can take up to a minute after the machine wakes from sleep or finishes booting before the authentication system is fully operational. Network connectivity issues can delay this substantially, especially if the system is part of an LDAP/OpenDirectory network.

Since you've been migrating accounts, try setting up a fresh new account and see if the problem occurs there. It may be possible to fix the problem by digging into the OpenDirectory database, but it may be easier to just recreate the problem account from scratch.


Since the UID was changed at some point in the past for NFS reasons, it is likely that the GUID and UID are out-of-sync. Try the following Terminal commands to see if unix and Directory Services are on the same page:

dscl . -read /Users/sbnoble GeneratedUID
dscl . -read /Users/sbnoble UniqueID

The UID output by "UniqueID" and "id" should match each other and the NFS UID you expect.

  • Thanks. Your first three alternatives don't seem likely in my case, but number four and five may be worth a look. Since the problem occurs so rarely, I don't think setting up a new account to see if the problem happens there is a viable strategy. I would have to do all my work in the new account, meaning I would have to migrate all my files to it. But perhaps I could do that, and just abandon my old account. Hmm … Feb 27, 2012 at 20:33
  • One thing I have forgotten to mention: Due to a need to access files over NFS, it is important to me to be able to select my uid. I have done that in the past, changing the uid from whatever the system assigned to me when setting up the account. That is perhaps a possible source of the current troubles. Feb 27, 2012 at 20:35
  • That would do it. OS X effectively has two user ids: the classic unix UID and its own GUID (GeneratedUID). So your UID and your GUID are out of sync. Fixing that is not too hard in "OS X Server" using the Workgroup Manager. But in client I think you would need to use the dscl command line too. See my edit above.
    – Seth Noble
    Feb 27, 2012 at 22:49
  • Hmm. My UniqueID and (unix) id both come out as 13799. The GeneratedUID is 781F6CC1-C5B3-4016-80AE-BE405C3EC721, not that I would expect that to match the others. Feb 28, 2012 at 8:28
  • The log entries you posted show the system having trouble finding GUID 71E63E19-F41E-4AF3-89A0-F50FE5185E5B. My guess is that there are multiple GUIDs and UIDs associated with your account. You will probably need to do some exploring with dscl to see what user records there are and perhaps consolidate them.
    – Seth Noble
    Feb 28, 2012 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .