I don't know if it's relevant, but 'chmod' isn't the command to fix this.
chmod changes the permissions on a file, but the script isn't complaining about permissions, it's complaining about ownership.
The command you want is chown (change owner):
sudo chown _postfix /Library/Server/Mail/data/mta/./guid_device_maps.plist
Hey scottyofmp -
Did you ever find a fix for this? I get the same error in Mountain Lion (though not an upgrade). What is happending for me is the self-sighned certificate works fine on services, but my GoDaddy cert does not. The services won't even start. Odd thing is my Lion production server, which loaded the exact same certificate file, works fine. :/
This is what you should be seeing on your system, I am assuming that all the ownerships and permissions are correct on all files and folders on my machine as it is reasonably new clean install of 10.8.2 Server 2.2 and my mail works fine.
I would change ownership/permissions to what you see below in red. NOTE - ownership is UID + GID.
You don't need to do the format "/./" it is redundant, just do something like .../mta/guid_device_maps.plist
server:Data Administrator$ pwd
server:Data Administrator$ ls -la
drwxr-xr-x 10 root wheel 340 Jan 3 13:40 .
drwxr-xr-x 4 root wheel 136 Dec 27 11:40 ..
drwxr-xr-x 3 root wheel 102 Dec 27 11:40 amavisd
drwxrwx--- 3 _postfix mail 102 Dec 27 18:22 db
drwxr-xr-x 6 nobody mail 204 Dec 27 18:22 gldb
drwxrwxr-x 7 _dovecot mail 238 Jan 3 13:40 mail
drwxrwx--- 6 _postfix mail 204 Dec 29 11:56 mta
drwxrwxr-x 2 _dovecot mail 68 Dec 27 11:40 rules
drwxr-xr-x 6 root wheel 204 Dec 27 11:40 scanner
drwxr-xr-x 16 root wheel 544 Dec 27 11:40 spool
server:Data Administrator$ sudo ls -la mta
drwxrwx--- 6 _postfix mail 204 Dec 29 11:56 .
drwxr-xr-x 10 root wheel 340 Jan 3 13:40 ..
-rw-r----- 1 root mail 2007 Dec 29 11:56 guid_device_maps.plist
-rw------- 1 _postfix mail 33 Jan 3 13:40 master.lock
-rw------- 1 _postfix mail 45056 Jan 6 15:10 postscreen_cache.db
-rw------- 1 _postfix mail 1024 Jan 6 15:03 prng_exch
Hey FromOZ - thanks for this info. It actually helped me in a different way than expected
My issue is actually that Mountain Lion, for whatever effing reason, is not properly importing production certs (in this case, from Go Daddy). Everything looks like it has completed properly, and Keychain actually shows a key file, but /etc/certificates is missing the .key.pem. All the other certificate files are there, but the key is not. That's why my mail (and other services) were not starting, and why I found myself here exploring other error messages. I can generate the .key.pem file with openssl, but it still doesn't work. No matter what I do, the .key.pem file does not get properly identified, or identified in a way that works.
The only exception is SMTP. If I manually generate the .key.pem file and ensure the /library/server/mail/config/postfix/main.cf properly refers to the file, then I can get SMTP (postfix) to run and work with the cert. But nothing else does.
Lion Server works just fine and imports the certs properly. It's not GoDaddy either, as even another Mountain Lion exported cert fails on import to a Mountain Lion box. Well, there is no error message, there just isn't a .key.pem file.
I have Apple Care for my server, but Enterprise Support says they won't support this since it is a "3rd party cert." Apples doesn't make server certs (only signing certs) so what they really mean is "any cert." I've pointed out it works fine with Lion, but that doesn't matter. I also pointed out it doesn't even work with the self-signed cert, but they still wont' help. Grrrr.
Do you have production certs you are using with Mountain Lion and SSL that work?
Hi - I know this won't make you feel any better.... but I have no problems with the certificate I purchased. I got a low cost single hostname certificate of server.xxxxxxx.com and I use that for all services on the OS X server. Means the mail server hostname is server.xxxxxxx.com (not a nicer mail.xxxxxxx.com) but that's fine.
I have checked and in /etc/certificates I see the following for that certificate.
-rw-r--r-- 1 root wheel 1866 Jan 9 15:23 server.xxxxxxx.com.D84EC18E60B49387A33DAA988EB3562F052AB3FD.cert.pem
-rw-r--r-- 1 root wheel 4473 Jan 9 15:23 server.xxxxxxx.com.D84EC18E60B49387A33DAA988EB3562F052AB3FD.chain.pem
-rw-r----- 1 root certusers 3617 Jan 9 15:23 server.xxxxxxx.com.D84EC18E60B49387A33DAA988EB3562F052AB3FD.concat.pem
-rw-r----- 1 root certusers 1751 Jan 9 15:23 server.xxxxxxx.com.D84EC18E60B49387A33DAA988EB3562F052AB3FD.key.pem
I got it from an intermediate authority RapidSSL, which then has GeoTrust Global as the root CA.
I use this website, http://sslchecker.com/sslchecker , to check the certificate and it comes up green for the whole cert chain.
Installing the certificate I basically (carefully!) followed the steps in this book on OS X Server and made sure the preparation steps were done correctly and fully. When I setup my Mac mini server I ended up throwing away the first install because I made a couple of fundamental setup errors which caused problems later. The marketing blurb says OS X Server is 'easy to use' I personally would totally disagree with that. Not that it is difficult to use, no it's not that its difficult but that if anything goes off the rails then the user quickly gets into deep doo doo. I call OS X Server the 'tar baby' server OS — the more one mucks around with it if there is a problem the more one gets 'stuck'.
Yeah I know, cold comfort for you, at this stage (not knowing the intracacies of where Server hides everything to do with certificates) the best I can suggest is to read up on standard ways of setting it up and see if you deviated.
Hey, sorry for the long delay... I appreciate your rely.
It actually IS good to know that your certificate installation worked. Was your server, by chance, an upgrade from Lion? It would be really nice to know that.
I've got 2 ML Server installations - this one I'm on for dev, and my "production" one now handling mail and web. Both of these were clean installations - the server being a new mac-mini preinstalled (even though I later blew it out and reinstalled).
Here's the behavior I consistently see. If I create my key in KeyChain and submit in CSR, and process the .crt everything looks fine *in KeyChain* in that the key is associated with the certificate, the certificate is valid and the chain is verified by the GoDaddy Intermediate which, in turn, is validated by the GoDaddy Grand Pooba signing CA. So as far as KeyChain is concerned, everything is fine. However, in regard to the server services requirements, the .key.pem file is NOT created in /etc/certificates.
In your [ls -la] result, you show the .cert.pem, .chain.pem, and .concat.pem - Those three are indeed created in /etc/certificates, but not the .key.pem file. I've gone through permissions, varied procedures to import certs, exported from other machines, laid a wreath on Jobs' sepulcher, all to no avail. I followed every step in every reference I could. The behavior was identical on both servers I tried it on. Everything worked perfectly on Lion Server, btw.
This is clear a bug in ML. I tried to get enterprise support to help but they wouldn't (the issue was "out of scope" for my support plan). They tried to say they didn't support "3rd Party" certificates, so I asked they what certificates they DO support. They said "Apple" certs but of course Apple only does code-signing. I'm not happy with their response, but I guess I understand. I'll follow up.
Anyway, the reason my services wouldn't start was because in postfix, my /Library/Server/Mail/Config/postfix/main.cf file was changed to include all certificate files. The [smtpd_tls_key_file] variable GET'S SET to the .key.pem file even though it doesn't exist. Oh, all configuration lines were uncommented as they should have been.
The behavior in dovecot was slightly different. The /Library/Server/Mail/Config/dovecot/conf.d/10-ssl.conf file did the same thing as postfix's main.cf in that it added all the right file references, except for the .key.pem entry assigned to [ssl_key] was left blank. It was uncommented, but blank.
In order to fix this, I had to export my cert from KeyChain, including the private key, to a P12 formatted file and then extract out the key.pem file via openssl: [openssl pkcs12 infile=file.p12 -outfile file.key.pem -nodes].
That creates the .key.pem file required. You then have to copy it over to the /etc/certificates, chown it to root and chmod to [certusers]. After that, you ensure the above config files are syntactically correct, start everything up, and you're good to go.
That's pretty much it. I appreciate your help on this!
Hi all, just to close off this thread..
Apparently this is not an error to worry about. The issue is that OS X server creates a file (unhelpfully) as root in a folder structure usually owned by the postfix process. Then when Postfix tries to take ownership it can't - the file being owned by root - and it displays the error.
It is not anything to be concerned about, just looks annoying.