13 Replies Latest reply: Jun 19, 2014 11:06 PM by Iggy Pelman
scottyofmp Level 1 Level 1 (0 points)

Have had this problem since upgrade from Lion Server. Log message as follows.


Sep  7 10:20:33 server.domainname.com postfix/postfix-script[99529]: warning: not owned by _postfix: /Library/Server/Mail/Data/mta/./guid_device_maps.plist


I have tried the "chmod" command but after restart root is the apperant owner. I am some what new to UNIX.


Thany you in advance.

OS X Mountain Lion (10.8.1)
  • 1. Re: Not owned by postfix
    Camelot Level 8 Level 8 (45,790 points)

    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

  • 2. Re: Not owned by postfix
    scottyofmp Level 1 Level 1 (0 points)

    Sorry, looked at notes wrong. I DID use the "chown". Tried the above command line again and get same error

  • 3. Re: Not owned by postfix
    Mark23 Level 3 Level 3 (975 points)

    Have you tried fixing permissions from Disk Utility?

  • 4. Re: Not owned by postfix
    scottyofmp Level 1 Level 1 (0 points)

    Yes, fix permissions and fix disk this morning, though that might fix the problem, It didn't.

  • 5. Re: Not owned by postfix
    Mark23 Level 3 Level 3 (975 points)

    I don't even have that file (/Library/Server/Mail/data/mta/./guid_device_maps.plist) at that location, only file there for me is master.lock

  • 6. Re: Not owned by postfix
    Thor HoG Level 1 Level 1 (0 points)

    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.  :/ 

  • 7. Re: Not owned by postfix
    FromOZ Level 2 Level 2 (405 points)

    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


    Be careful....



    server:Data Administrator$ pwd



    server:Data Administrator$ ls -la

    total 0

    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

    total 112

    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

  • 8. Re: Not owned by postfix
    Thor HoG Level 1 Level 1 (0 points)

    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?



  • 9. Re: Not owned by postfix
    FromOZ Level 2 Level 2 (405 points)

    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.

  • 10. Re: Not owned by postfix
    Thor HoG Level 1 Level 1 (0 points)

    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!




  • 11. Re: Not owned by postfix
    FromOZ Level 2 Level 2 (405 points)

    I had clean install of Server 2.2 totally from scratch on clean install of 10.8.2.


    I followed instructions from one of the ML OS X server books out there and on my second go got certificates working. At this stage not really expert in the area of certs, just glad mine working cleanly!

  • 12. Re: Not owned by postfix
    FromOZ Level 2 Level 2 (405 points)

    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.

  • 13. Re: Not owned by postfix
    Iggy Pelman Level 1 Level 1 (20 points)

    I simply changed the ownership of the file to _postfix and I've not had any problem as a result (but the error message went away).


    sudo chown _postfix /Library/Server/Mail/Data/mta/./guid_device_maps.plist