Why do postconf -n and postfix reload produce unexpected output on OS X Server 5?

If you’ve been a long-time OS X Server user, especially from the days prior to OS X Server 5, then you’ll find that commands that used to work fine, suddenly produce unexpected output.

For example:

postconf -n

may show you Postfix parameters which are completely different from what you would expect them to be.


postfix reload

may show you errors that shouldn’t be there.

The reason for this is quickly found. In recent years, and especially so in OS X Server 5, Apple has been moving server related binaries to:


and server related configuration files to:


Thus, when you call postconf -n you are actually using /usr/sbin/postconf -n and displaying the contents of /etc/postfix/main.cf instead of using /Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -n and displaying the contents of /Library/Server/Mail/Config/postfix/main.cf.

While it makes lots of sense and allows for unbundling OS X Server from the underlying OS (OS X Server 5 works on both, Yosemite and El Capitan) it is a transition which is still not complete and has its inconsistencies. Some commands (e.g. mailq) are still in their old locations due to compatibility issues with older software (sendmail in this case).

Tip: Use postqueue -p instead of mailq

Although it can drive you mad at times, overall, it is a welcome change made for good reasons.

That said, let’s see how we can make sure we use the correct binaries and configuration files.

As mentioned, binaries (applications) for Postfix are now to be found under /Applications/Server.app/Contents/ServerRoot/. So the first thing we need to do, is to use those binaries, instead of the ones under our main root /.

There are multiple ways of achieving this.

1. Use the full path to the binary:

Instead of simply typing:

postconf -n 

we would need to type:

/Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -n

Not exactly elegant, but it works.

2. Modify the PATH environment variable:

While this requires a little bit of work upfront, it will save you lots of time in the long run.

If you look inside /private/etc/paths.d/ you will find a file called com.apple.server. This in turn contains the following two paths:

Unfortunately, paths added inside paths.d will be added to the end of $PATH. So if you issue for example postfix reload, you will still use /usr/sbin/postfix instead of /Applications/Server.app/Contents/ServerRoot/usr/sbin/postfix

Note: There are many ways of modifying the PATH environment variable. Choose the one you prefer or use the method outlined below.

In your users home directory (e.g. /Users/myadminaccount/) create a file called .profile.1

Inside it, add:

export PATH="Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/mysql/bin"

Note: If you already have other custom paths set up, you will need to adapt above instructions to reflect those paths as well.

Save the file, close and re-open your terminal window (or exit and re-connect via SSH) and you should be good to go.

If in doubt, issue:

which postfix

and it will show you which command is going to be used.

The steps outlined in this article are not only valid for Postfix, but pretty much for any server related binary that has been moved under /Applications/Server.app/Contents/ServerRoot/.

  1. If you are unsure about how to edit a configuration file, have a look at our tutorial on how to edit text files 
1 reply
  1. Allan
    Allan says:

    I have been worried about this issue — particularly that it was a symptom of a more serious problem — for about 2 years. Thanks very much for this very informative explanation.

    The workaround by using a .profile that overwrites $PATH worries me a bit, though, because Apple could change the default again, commands unrelated to this issue could stop working, and I would certainly have forgotten that I set up this .profile file months or years earlier. For me, however, the big deal was knowing that the problem is fairly benign and knowing that I can work around it if I have to.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *