You don't exist, go away! 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.
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.

Update

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
id


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