I have non-admin users who need to change their password. The passwd command is apparently limited to administrators.

On the Server website, there's a change password link, but it doesn't work, and users receive an error. Internally, Mac OS X logs the following message:

Jan 21 01:56:02 domain.com collabd[247]: [CSAuthService.m:506 ab93000 +206ms] Could not change password for user 1234 with error Error Domain=com.apple.OpenDirectory Code=4001 "Operation was denied because the current credentials do not have the appropriate privileges." UserInfo=0x1234567890abc {NSLocalizedDescription=Operation was denied because the current credentials do not have the appropriate privileges., NSLocalizedFailureReason=Operation was denied because the current credentials do not have the appropriate privileges.}

I have the option in the website service checked to allow changing passwords. What would be causing this error?

EDIT: Users created with the Server app are fine, but the trouble is with users created with dscl on the command line. Here are the exact commands used to create a test user named "qwer":

sudo dscl . create /Users/qwer UniqueID 507
sudo dscl . create /Users/qwer PrimaryGroupID 20
sudo dscl . create /Users/qwer UserShell /bin/bash
sudo dscl . create /Users/qwer NFSHomeDirectory /Users/qwer
sudo mkdir /Users/qwer
sudo chown qwer:staff /Users/qwer
sudo passwd qwer

I then executed sudo dscl . read /Users/qwer and compared it with sudo dscl . read /Users/uiop for a second test user.

In the records, the following keys are unique to the user created with the Server app:


These match:


And these are unique to each user (or in the case of Password are obfuscated):


I checked AuthenticationAuthority but the only thing different is the username in the string, so that could be considered equivalent as well.

Additionally, groups qwer and groups uiop give exactly the same output.

There doesn't appear to be anything preventing "qwer" from changing their password except for the fact that their user account was created on the command line; however, the dscl method should be perfectly valid.

2 Answers 2


According to this old article (10.3!), the lack of a _writers_password property in the NetInfo database would prevent users from changing their password. That's really outdated, but it seems like a reasonable place to start.



From some other sources (as far back as "Running Mac OS X Tiger" page 136) it looks like _writers_passwd is a list of users who can change that particular user's password. So, setting it to the username should be sufficient.

  • That's it exactly. I didn't even see that... I was thinking they were for the picture but I apparently missed the passwd one. Looks like those should be added to any script that creates users if they need to be able to change their own password.
    – jstm88
    Jan 22, 2014 at 2:25
  • By the way, are you on 10.9 server? I use a similar script as everyone else (without _writers_passwd) on 10.5, 10.6 and 10.8 servers, and have not hit any issues.
    – Kent
    Jan 22, 2014 at 4:19
  • Yep, 10.9, and I agree, I think it may be new to this version because I've done this on past servers without issues. Time to update scripts, probably with each of the _writers_* items, just to be safe. I wonder if 10.5-10.8 actually did it wrong and ignored those values, and on 10.9 they "restored" the proper behavior. It would explain why nobody seems to care about these keys when creating users despite the old documentation mentioning it.
    – jstm88
    Jan 22, 2014 at 7:30
  • 1
    And honestly, would it really hurt Apple to provide useradd and groupadd equivalents that handle it properly? Keeping track of all the right keys to keep the script up to date is kind of a finicky solution, since missing something obscure like this can lead to these kinds of tricky, hard to track bugs. :) Oh well.
    – jstm88
    Jan 22, 2014 at 7:33

First, the passwd command doesn't require any administrator access to change your own password.

I think you have a certificate problem. Have a look in the Certificate pane of the Server app and check that all your certificates are still valid and that there is no warning about a service not using a certificate in the bottom pane. It looks like the web server is not being allowed to make the password change for some reason.

You could also go to /Library/Server/Wiki/Config and run plutil on all the plist files to make sure nothing is too wrong there. I'd also check that all the file permissions look sane.

Do you get the same error for both standard and admin users? Can an admin user successfully check into Profile Manager?

  • The server is using a self-signed certificate, and it isn't expired. I'm not sure what this would have to do with the passwd command though. According to this article the passwd command is restricted to admins. I'm not sure why, though.
    – jstm88
    Jan 21, 2014 at 18:31
  • Checking on Server 10.8 and on a 10.9 machine passwd works fine for both standard and admin users to change their own password. Jan 21, 2014 at 21:56
  • See additional information included in the question. It appears creating users on the command line is different, but I'm not sure how.
    – jstm88
    Jan 21, 2014 at 22:33
  • So the real question is how to create a user from the command line. Give me a few hours to check my old scripts. Jan 21, 2014 at 23:12
  • Not exactly... I can create users from the command line, and the steps are in line with any one of dozens of articles on the subject. But there's something missing that prevents passwd from working. If your script does anything different, I'm interested in what it is so I can work it into mine. :)
    – jstm88
    Jan 21, 2014 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .