6

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.

Jason Salaz
  • 24,471
Harald Hanche-Olsen
  • 4,149
  • 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? – Jason Salaz Feb 27 '12 at 07: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). – Harald Hanche-Olsen Feb 27 '12 at 08:12
  • http://apple.stackexchange.com/questions/43940/when-i-open-terminal-i-get-an-i-have-no-name-prompt is very similar thread to this one. – mspasov May 11 '12 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. – Harald Hanche-Olsen May 12 '12 at 19:34

1 Answers1

2

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.

Seth Noble
  • 1,114
  • 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 … – Harald Hanche-Olsen Feb 27 '12 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. – Harald Hanche-Olsen Feb 27 '12 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 '12 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. – Harald Hanche-Olsen Feb 28 '12 at 08: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 '12 at 15:44
  • No luck with that either. I have run dscl . readall ITEM for every ITEM in the output of dscl . list /, and don't see that GUID (71E63E19…) anywhere. I don't see any extra accounts either (there are very few accounts on my system apart from the system provided ones). In any case, it is not at all clear to me what kind of object should be associated with that UID. – Harald Hanche-Olsen Feb 28 '12 at 16:53
  • That GUID may exist in some other database or plist, and the fact that its not in directory services may be what's causing problems. Maybe a sudo fgrep -l -r -i 71E63E19-F41E-4AF3-89A0-F50FE5185E5B /System/ /Library/ to search for files containing that string. But that's pretty much my last idea for where to look. – Seth Noble Feb 28 '12 at 20:03
  • Tried that too, (but with a find/xargs pipeline to avoid symlinks and sockets and so forth), no luck. I search /var as well. If that GUID is there, it might be in binary format perhaps. Thanks for all the help. At least, you have helped me rule out a good number of possibilities. – Harald Hanche-Olsen Feb 29 '12 at 11:56
  • Now I don't exist again. This time, there is a different GUID for a node it can't find. So I looked back in the logs, and find that this is a quite common occurrence, with different GUIDs all the time. So there may be some temporary object that it can't find. And on all the other occasions, I don't see the same problem, so the log entry may even be unrelated to the problems I am seeing. (This time around, the problem is happening at a particularly inopportune time. So I'll try a reboot and see if things work afterwards. – Harald Hanche-Olsen Mar 01 '12 at 18:34
  • Rebooted, things are normal once more. No further GUIDs of objects not found so far in the log. – Harald Hanche-Olsen Mar 01 '12 at 19:20
  • I'm accepting this answer, even though it did not actually solve my problem. (But there are some good insights in it.) It solved itself with some OS upgrade or other. And I never got to the bottom of its cause. – Harald Hanche-Olsen Feb 18 '18 at 08:42