Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As much as I would like to figure out the problem, at this point too much time has been invested in deleting a stupid key when I already had a solution (the command line creation) that works. I'm going to delete the user and run the commands that I need. It would still be wonderful to have an answer, but I don't think that is going to happen.

I have a network of slaves attached to buildbot, each with a buildbot user account. I'd like their accounts to not have passwords (read: not an empty password). I did this successfully on one of the boxes as a great consequence of remotely creating the user and not setting the password in the procedure.

Two other OSX machines that I set up through the GUI do have passwords, and I'm wondering if there is a way to remove the password without leaving it empty. I looked through a bit of the documentation for dscl and passwd, but they don't have the options I'm looking for. I could set them to be some random string of numbers. Would that be just as effective? Is my description equivalent to having an empty password and locking the account (as in this disscussion for linux)? If so, how do I lock an OSX account?

The second part of my question is in regard to the way that I originally created the users. Below are the commands and they seem to work fine but I wonder if I'm missing some important setting --the buildslave did start and execute jobs though.

sudo dscl . -create /Users/buildbot
sudo dscl . -create /Users/buildbot UserShell /bin/bash
sudo dscl . -create /Users/buildbot RealName "BuildBot"
sudo dscl . -create /Users/buildbot UniqueID <ID>
sudo dscl . -create /Users/buildbot PrimaryGroupID 61
sudo dscl . -create /Users/buildbot NFSHomeDirectory /Users/buildbot
sudo mkdir /Users/buildbot
sudo chown buildbot /Users/buildbot

EDIT: For the machines that already had accounts w/ passwords created through the System Preferences, the commands suggested by Dan Black do not actually delete the Password key,

sudo dscl . -delete /Users/buildbot Password
sudo dscl . -read /Users/buildbot Password

The output to the second command is,

Password: *******

Continuing as if the password was deleted, I run

sudo dscl . -create /Users/buildbot Password '*'
su buildbot

And the previous password accesses the account. This is on OSX 10.5.8 and 10.6.8.

sudo dscl . -change /Users/buildbot Password 'OLDPASS' '*'
su buildbot

This also does not change the password, and OLDPASS can switch users when asked for the password.

Here is the complete key-value pair output for the user i'm having trouble with --created through sys-preferences. To clarify an inconsistency, this machine uses user 'developer' not 'buildbot', but the previous commands were all done the same just with the obvious replacement

Amoy:~ lyn$ sudo dscl . -read /Users/developer
dsAttrTypeNative:_writers_hint: developer
dsAttrTypeNative:_writers_jpegphoto: developer
dsAttrTypeNative:_writers_LinkedIdentity: developer
dsAttrTypeNative:_writers_passwd: developer
dsAttrTypeNative:_writers_picture: developer
dsAttrTypeNative:_writers_realname: developer
dsAttrTypeNative:_writers_UserCertificate: developer
AppleMetaNodeLocation: /Local/Default
AuthenticationAuthority: ;ShadowHash; ;Kerberosv5;;developer@LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;
 developer for auto testing
GeneratedUID: BF95A834-A7F1-4DDD-8DFB-6B80B8120CA7
NFSHomeDirectory: /Users/developer
Password: ********
 /Library/User Pictures/Fun/Flippers.tif
PrimaryGroupID: 20
RealName: Developer
RecordName: developer
RecordType: dsRecTypeStandard:Users
UniqueID: 512
UserShell: /bin/bash
share|improve this question
I'm confused: you want them to not have a password, but not have a blank password? – Canadian Luke Jan 10 '12 at 16:30
yeah. I guess the same affect may be having a blank password and locking the account? (from looking around,…). Would this be correct? – nlucaroni Jan 10 '12 at 16:41
That looks right, but I didn't quite understand your question based on wording alone. I would recommend editing it to say so, and if that is the answer, paste what was said and give credit as an answer – Canadian Luke Jan 10 '12 at 17:27
No it's not right for OSX; passwd -l is for location not lock. I edited the question accordingly. Does it need further clarification? I thought I was being pretty precise. – nlucaroni Jan 10 '12 at 17:34
My confusion came from your second sentance, that's all. And the OSX part is what drew me in, but I don't use dscl to make users, I use the GUI part – Canadian Luke Jan 10 '12 at 17:45
up vote 2 down vote accepted

I think the problem you're having with @Daniel Beck's answer is that the password isn't stored in the user record's Password attribute, but as a shadow hash file in /var/db/shadow/hash/USERGUID, and the AuthenticationAuthority attribute still points to that. This seems to work for me:

sudo dscl . -delete /Users/buildbot AuthenticationAuthority
buildbotGUID=$(dscl . -read /Users/buildbot GeneratedUID | awk '{print $2}')
sudo rm "/var/db/shadow/hash/$buildbotGUID" "/var/db/shadow/hash/$buildbotGUID.state"

Ideally, you should also remove the account's Kerberos principal (OS X clients run their own "local" Kerberos realm, and it occasionally gets underfoot). But that's a bit more complicated, and I think depends a fair bit on which version of OS X you're using.

BTW, if the above doesn't completely do the trick, try this:

sudo dscl . -create /Users/buildbot AuthenticationAuthority ";DisabledUser;"
share|improve this answer
Disabling the account is functionally equivalent to locking it? – nlucaroni Jan 11 '12 at 0:24
Mostly; there are probably some subtle differences. Note that the "disabled" setting is in the AuthenticationAuthority attribute, so generally it only disables authentication, not other account functions. I don't know enough about buildbot to know this will interfere with it. – Gordon Davisson Jan 11 '12 at 1:10

You need to set the password to a single * character (asterisk, star) using dscl.

sudo dscl . -create /Users/buildbot Password '*'

Be sure to escape or quote (as shown) it so it doesn't get interpreted by your shell.

This will (when read) not be displayed as ******** like any other password, but as *, which just means "no password".

share|improve this answer
It's probably derived from the use of a * in passwd files that only contain password hashes to indicate that a user has no password. – Daniel Beck Jan 10 '12 at 18:10
This did not update the password; after executing the command I can still use the old password. is it possible that it should be -change instead of -create? – nlucaroni Jan 10 '12 at 18:20
@nlucaroni Did you -delete /Users/buildbot Password before executing that line? My reference starting point was the code in your question, which didn't mention creation of a password. – Daniel Beck Jan 10 '12 at 18:21
No, I did not delete anything; I thought you were referring to my earlier made accounts. Do I have to do this to the newly created account through the command line? It appears to be doing what I want without setting that key at all. – nlucaroni Jan 10 '12 at 18:24
@nlucaroni Now I understand what you mean. It's difficult with multiple questions combined into one. Run dscl with the arguments in my earlier comment first to delete the old password, then set the new one to '*'. -change might work, I haven't tested it myself though. What do you mean by without setting that key at all? What's the output of dscl . -read /Users/buildbot Password? – Daniel Beck Jan 10 '12 at 18:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.