You don't exist, go away!

Solution 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.

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.