9 Replies Latest reply: Oct 20, 2012 1:43 AM by Isaka Traore
°Bernz° Level 1 (10 points)

Hello all,


I've been trying to make my Profile Manager run under 10.8 and it just won't run... I've upgraded from 10.7, in which it worked well, but I did get at the start the "Error reading settings" error...


When trying to start Profile Manager under 10.8 server, I get a popup error with this message:


Capture d’écran 2012-07-30 à 19.06.22.png

(An error occured on the server while reading settings. The error occurred while reading setting for the Profile Manager service.)


I'm familiar with the wipeDB.sh command and tried to run it, but got an error. The error got a bit more explicit when I ran this command:


sudo serveradmin settings devicemgr


For which I got this error (I've cut it a bit since it's long...):


Jul 30 18:59:55 gimli.private ProfileManager[12172] <Info>: Making sure Rails is configured properly
Jul 30 18:59:55 gimli.private ProfileManager[12172] <Info>: Running rake command: '/usr/bin/rake db:create'
Jul 30 18:59:56 gimli.private ProfileManager[12172] <Info>: Output of rake command '/usr/bin/rake db:create:
          FATAL:  role "_devicemgr" does not exist
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:941:in `initialize'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:941:in `connect'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:941:in `connect'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:217:in `initialize'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:37:in `new'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:37:in `postgresql_connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `send'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `new_connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:245:in `checkout_new_connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:188:in `checkout'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:184:in `loop'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:184:in `checkout'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:183:in `checkout'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:98:in `connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:326:in `retrieve_connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:123:in `retrieve_connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:115:in `connection'
          /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/vendor/rails/railties/lib/tasks/databases.rake:70:in `create_database'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:636:in `call'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:636:in `execute'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:631:in `each'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:631:in `execute'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:597:in `invoke_with_call_chain'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:590:in `invoke_with_call_chain'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:583:in `invoke'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2051:in `invoke_task'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2029:in `top_level'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2029:in `each'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2029:in `top_level'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2068:in `standard_exception_handling'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2023:in `top_level'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2001:in `run'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2068:in `standard_exception_handling'
          /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:1998:in `run'
          Couldn't create database for {"database"=>"device_management", "pool"=>5, "adapter"=>"postgresql", "encoding"=>"UTF8", "username"=>"_devicemgr"}
          (in /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend)
Jul 30 18:59:56 gimli.private ProfileManager[12172] <Info>: Running rake command: '/usr/bin/rake --trace db:migrate'
Jul 30 19:00:00 gimli.private ProfileManager[12172] <Info>: Output of rake command '/usr/bin/rake --trace db:migrate:
          rake aborted!
          FATAL:  role "_devicemgr" does not exist


My OS X Server is an upgrade from 10.7, so I'm surprised the role does not exist, especially that in /etc/group, the group is there.


Capture d’écran 2012-07-30 à 19.15.41.png


Can anyone help me get my Profile Manager back on track?



OS X Mountain Lion
  • Doctor Phil Level 1 (15 points)

    I had this issue as well after an upgrade from Lion Server to OS X 10.8 Server.  Rather than try to figure it out what went wrong, I just did a reinitialize of the whole server.  I'm not sure I would recommend this approach if you have a lot of settings you're trying to import from Lion, but if all else fails, this approach seems to work...


    Quit the server app.


    Tempoarily move the server app from applications folder to your home directory...

    sudo mv /Applications/Server.app ~/server.app.backup


    Backup the server library to your home directory...

    sudo mv /Library/Server ~/server.library.backup


    Then move the server app back to the applications folder...

    sudo mv ~/server.app.backup /Applications/Server.app


    Start the server app.  Once it initialize services, you can copy over from backup what you want from your  ~/server.library.backup folder (like your web directory, if you've made changes there).


    Again, this approach isn't for everybody, but it worked for me.

  • °Bernz° Level 1 (10 points)

    Hi Doctor Phil,


    That is actually a neat trick! Thanks for the help!


    Unfortunately, one of the things that I lost was my Open Directory users... And, thanks to the Apple developers, the backup feature of 10.8 for OD is gone, so I have to recreate them and reassign the rights...


    If you know how to get my old users back from the /Library/Server folder, that would be peachy!



  • Doctor Phil Level 1 (15 points)

    To be honest, I only have a few local users that I kept in an OD master, and those survived the upgrade and my reinitialization.  I don't believe the OD master is in the /Library/Server folder anyway. (I think it's in /etc/openldap.) If you have a Time Machine backup, you might be able to restore from that.  But if you only have a few OD users, it might be easier to just add them back in.  Sometimes it's easier to just start fresh.

  • °Bernz° Level 1 (10 points)

    You know what, in most circumstances, I'd say you're entirely right.




    I'm using this ML Server in my SOHO to do some tests for some clients, and I have other macs connected to it, including my wife's... Now, she has a user created in OD and she is using a mobile profile. I'm now entirely sure how the mobile profiles work, but my guess is that it must be using a GUID of some sort to identify the user account, and not just the user name.


    Sooooo, if I recreate the users in OD, I should be another GUID, and this means that the mobile accounts might go "bye bye"...


    I can just see my discussion with my wife tomorrow as she tries to log in but it crashes...


    I'll know tomorrow, I guess...


    Anyway, thanks for your great help!

  • jaydisc Level 4 (1,400 points)

    WipeDB.sh has been moved to inside the Server.app bundle:


    /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/wipeDB. sh

  • +Mela- Level 1 (0 points)

    Same issue after upgrade from OSX 10.7 (Lion) Server to OS 10.8 (ML) + Server.app

    After reading this discussion i try this:

    0) >sudo Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/wipeDB. sh


    but it abnormaly-ends whit message:

    Couldn't create database for {"encoding"=>"UTF8", "adapter"=>"postgresql", "database"=>"device_management", "username"=>"_devicemgr", "pool"=>5}

    (in /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend)

    rake aborted!

    FATAL:  role "_devicemgr" does not exist

    1) connect to postgres with role _postgres and:

    CREATE ROLE _devicemgr LOGIN


    2) sudo Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/wipeDB. sh

    again and this time it works


    sudo serveradmin settings devicemgr is OK.

    I'm not OSX server expert, I'd like to know if you think that this solution may have contraindications.

  • Brian Tanner Level 1 (0 points)

    Could you provide more info.  I've not used postgres before and I Don't know how to connect to it, but I Would love to have this exact problem solved on my machine.

  • Isaka Traore Level 1 (0 points)

    I've had the same error popup on my Mac Mini (re this initial thread posting), it turned out to be a really tricky issue. To this writing I have not found a solution, but I could trace some of the things going wrong.


    If you haven't installed any PostgreSQL or Ruby on Rails programs on this machine, I would suggest you 1) delete Server Manager app, b) reboot, then c) reinstall Server Manager app from the App Store, and see if that solves it. If this doesn't work for you then you risk spending as much time as I did and not get a resolution. To see why I say this, check out the rest of this (long) reply.


    Here is my take: in my opinion Server Manager is not properly sand-boxed, it tries to keep itself isolated from the rest of the OS but apparently some tools and/or libraries are clashing all over the place, that is if you ever experience this kind of issue.


    My experience:

    1. When I first upgraded to ML, Server Managed seemed to run fine, I did some test, then left it alone (for later)
    2. Then, at some stage, I started adding "ruby on rails" using RVM, and Postgres as database. I never really noticed a thing then.
    3. As I finally wanted to configure web server instances, these errors started popping up and have been doing so all the time.


    I initially thought of giving up immediately then realised that I needed web servers to run in this box, hence needed Server Manager. With the migration to Clang, Gcc based open source programs are tricky to build and I really didn't want to venture down that sort of wormhole, so I thought I'd try harder first.


    After many hours poking around, I have the following findings (starting with Console app to view the trace log):

    • Server Manager ships with its own copy of the entire Ruby on Rails stack, and PostgreSQL
    • In my case, its only after I saw these error messages that I realised there could be a clash between three things: default system Ruby and Ruby on Rails, my (user) installed Ruby on Rails stack on RVM, my (user) installed PostgreSQL server and client and the version of PostgreSQL embedded in Server Manager
    • The error [ ' role "_devicemgr" does not exist ' ] is due to (some instance of) PostgreSQL client failing to authenticate Server Manager application user role. This problem in turn may be due to the presence of either (a) either more than one copy of PostgreSQL present on the machine, or the user context where the command 'sudo serveradmin settings devicemgr' is running has access to PostgreSQL clients that are getting in the way of Server Manager utilities
    • I created symbolic links in '/usr/local' to get around PostgreSQL issues, created a databse 'device_management'  and a role '_devicemgr' inside it. I stopped seeing PostgreSQL errors but the Ruby on Rails errors remained


    I initially thought I could just remove my user installed copies of Ruby on Rails and PostgreSQL. But that didn't solve it.


    So I tried to run the commands manually. If you look in the folder '/Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend' you will find the Profile Manager (Ruby on rails) app, there sits the file 'wipeDB.sh', which is supposed to reconstruct Server Manager database, as long as this fails to run you will not get Server Manager running again. I even tried to change the PATH variable, putting this in front '/Applications/Server.app/Contents/ServerRoot/usr/bin', and do various retries, so far it isn't working and throws the same Ruby on Rails errors that I saw when clicking items inside Server Manager, which, to me, means that the issue is somewhere higher up the stack that isn't visible in log files or anywhere else.


    I tried to replace the default Ruby on Rails stack but run into other issues that I can't describe here (too long already).


    After many more failed attempts, I removed Server Manager app, restarted the Mac Mini, and installed it again (from the App Store purchase history). That too didn't solve it.

  • Isaka Traore Level 1 (0 points)

    Problem FIXED on my Mac Mini!


    Here is how I solved it:


    1. Be sure you have no user installed PostgreSQL running (as yourself, run: 'pg_ctl stop' if necessary)

    2. Run these commands (so that postgres client can find the socket to talk to the server):


    $ sudo ln -s /var/pgsql_socket/.s.PGSQL.5432 /tmp/.s.PGSQL.5432

    $ sudo chown _postgres:_postgres /tmp/.s.PGSQL.5432


    3. Start Server App (this time you shouldn't see any error dialogs, if the previous succeeded)

    4. Start the service 'Websites' (without this your next action will fail, perhaps because noone is listening)

    5. Run these commands:


    $ cd /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend

    $ ./wipeDB.sh


    # START Comment: after about 40 secs wait this should complete without any errors, the output should look like this:


    $ ./wipeDB.sh

    devicemgr:state = "STOPPED"

    postgres:state = "RUNNING"

    (in /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend)

    (in /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend)

    devicemgr:state = "STARTING"



    # END Comment


    6. You are done, Server Manager should run smoothly now.



    Well I guess it's my curse trying to give up on an technical issue, it never works, ***** my time, but I'm glad to share how Ive' solved it.


    Update: forgot to use 'sudo' to create the symbolic links, necessary due to file ownership