dscl . create /Users/test
dscl . create /Users/test UniqueID 420
dscl . create /Users/test PrimaryGroupID 420
dscl . create /Users/test UserShell /bin/bash
dscl . create /Users/test NFSHomeDirectory /tmp
dscl . create /Users/test RealName Test
dscl . create /Users/test Password test
This creates a user that's visible in sysprefs/Accounts.
dscl . create /Users/test Password "*"
This hides the user. Make sure you quote the "*" or it won't work.
EDIT: I accidentally managed to recreate googletorp's situation of not being able to hide a user by setting his password to "*", and I discovered how to fix it. This time, I had created a user using dsimport, like this:
dsimport /dev/fd/0 /Local/Default I --template StandardUser << EOF
test:*:520:520:Test user:/Users/test:/bin/bash
EOF
But in that command, the * is taken to represent a literal one-character password of *
, and so dsimport creates an AuthenticationAuthority property for the user and sets the password property to the shadow hash of *
(which shows up as ********
in dscl, as for all passwords). After that, attempting to set the password to "*" using dscl just keeps setting the password to a literal *
, instead of disabling the password. The solution is to delete the unwanted property, and then disable the password:
sudo dscl . delete /Users/test AuthenticationAuthority
sudo dscl . create /Users/test Password "*"
This hides the user.
Having a password for your _postgres user isn't a particularly bad idea at all. – Hasaan Chop – 2009-11-15T17:36:35.170
1The postgres docs actually recommends the opposite, that way only system users can access postgres, and there is one less password to remember / security risk. – googletorp – 2009-11-16T11:20:18.137
Have you tried deleting and recreating the user? – Chealion – 2009-11-22T19:35:11.540
Yeah, I've tried that a few times actually. You need to somehow set the passwd to disabled as not having a passwd is not enough. This is the pain point I haven't been able to overcome. – googletorp – 2009-11-22T20:33:11.890