Skip to main content

When Docker installs on a machine, it asks the user for root privileges to finish its installation process after you start it the first time. In our environment, we decided that it's best users don't need to enter any sort of credentials to finish the installation of an application. So, via a trail of troubleshooting steps I found online and some trial & error, I was able to put together an installer that does not need root privileges to finish its installation.

Use the following directions to create a version of the installer that does not require Admin Rights. If you are already familiar with making JSS policies and using Composer, check out the TLDR section at the bottom.

  1. Download Docker For Mac
  2. Mount the Docker DMG
  3. Open Composer
  4. Click on New
  5. Select Normal Snapshot
  6. Click Next
  7. Name the Snapshot and click next
  8. Once the Snapshot has finished creating, drag the Docker application into the root Applications folder
  9. Open Applications, and then open Docker
  10. Docker will post an introductory window, click OK
  11. Docker will ask for privileged access, click OK
  12. Enter your Admin credentials and click okay
  13. Docker will run its final installation steps
  14. Click Got It after Docker has finished running its post-installation
  15. In Composer, click Create Package Source
  16. Drill down Library>LaunchDaemons
  17. Select the com.docker.vmnetd.plist file
  18. Ensure that the file's owner is root, and group is wheel.
  19. Check the box for X (execute) on the Owner row. Verify that it states Mode: 744 (not 644)
  20. Drill down Users>{username}>Library>Containers>com.docker.docker
  21. Delete the Data folder within the com.docker.docker folder
  22. Ensure there are no additional folders unrelated to the Docker installation in the package source. In my case I removed the Saved Application State folder.
  23. Once you've done this, click on Build as DMG and save to your package build location
  24. Open Casper Admin and drag the DMG into Casper Admin to upload.
  25. Change the settings on the DMG to turn on FEU (Fill Existing User Template)
  26. Categorize the file
  27. Save
  28. Log into the JSS and Create the Docker policy.
  29. Place the DMG in the policy
  30. Set the policy to restart after install (Restart Options>User Logged In Action> Restart)
  31. Add Files and Processes, add the following one liner to Execute Command: /bin/launchctl load -Fw /Library/LaunchDaemons/com.docker.vmnetd.plist
  32. Setup to install from Self Service

TLDR Version;
Install using a composer snapshot as normal.
The only major differences are as follows:
Change /Library/LaunchDaemon/com.docker.vmnetd.plist to 744 and root:wheel
Delete the Data folder found in Users/{username}/Library/Containers/com.docker.docker
Save as DMG, place on Casper Admin with FEU enabled
In Policy: Ensure that the computer restarts after install. Add the following one liner in Execute Command:
/bin/launchctl load -Fw /Library/LaunchDaemons/com.docker.vmnetd.plist

Trying this now...

Worked like a charm!

Hey @Jacher - have you had a chance to package / distribute an update? As a test I've successfully packaged Docker Edge and now just packaging the update in preparation to test the distribution of this.

I'd be interested to see if you have investigated how to suppress any update notifications. I've already had a support ticket raised about not being able to install the update without elevated rights.

Thanks!

This process seems to be broken in the recent 1803 drop. Error messages suggest that the docker app is looking for the folder path of the compose user rather than the local user when installed on a remote host. I'll work through the issue and post any updates.

Does anyone know if this is possible still? I'm hoping to do this for our company as well but also get an error. It would be nice if there were some commands for it to extract what it needs that could be used in a script. Similar to the Xcode post install commands. It's hard to find any information like that on Docker though.

Hi @DakotaS96 - I've been working with Docker Engineering to see how best to package and distribute at scale. The process hasn't significantly changed although there is now a dependency on accessing the com.docker.docker directory. It's not automatically recreated as previously mentioned.

Let me see if a support ticket or feature request exists so you can add your contact details.

In a change to the above documentation:
Step 21: DO NOT DELETE the Data folder within the com.docker.docker folder
Step 31: Create an alias mapping your local user's account to your packaging account. ln -s /Users/$CURRENT_USER/ /Users/docker-package-user

Awesome! Looks like that worked. Thanks for the update!

I'm not sure if I needed to but in order to keep both step 31's I created a script to run after the package install.

!/bin/sh

currentUser=ls -l /dev/console | cut -d " " -f 4

launchctl load -Fw /Library/LaunchDaemons/com.docker.vmnetd.plist
ln -s /Users/$currentUser/ /Users/docker-package-user

@jaz Might be a bit late, but i asked myself the same thing. Found out that theres a Preferences .plist in /User/username/Library/Preferences/com.docker.docker.plist. you can disable Autoupdate via:

defaults write /Users/$username/Library/Preferences/com.docker.docker.plist SUEnableAutomaticChecks 0

But it will just uncheck the checkbox, user can change it if he wants to.

@jaz @DakotaS96 When you run the "ln -s /Users/$currentUser/ /Users/docker-package-user" command, who exactly do you mean as the Docker-Package-User? I'm assuming that I'm supposed to substitute that out with a user specific to my environment. Is it supposed to be an admin account? I should also mention that don't know much about docker, so that probably doesn't help.
Thanks for posting updates on this! It seems to be working without that command oddly enough.

@jaz @DakotaS96 @sdb2029 I am interested in some more detail about the package user as well. I have to deploy this app to users that do not have and cannot have admin rights. I followed @Jacher 's steps and wound up with a copy of Docker that is happy to install but hits a fatal error on launch and cannot reset to factory, cannot start fully so I can uninstall. /halp/

I have come across this same issue when installing applications that use the squirrel.framework to autoupdate (Yammer, MS Teams, et al).
The fix I came to was to install those apps in the User template in a users local Application folder (/System/Library/User Template/English.lproj/Applications) for new users and placing via script the squirrel App in existing user's local Application folder.

This allows the local user to never be prompted for admin rights as they have full rights to their local Applications folder, Applications within that folder and the subsequent sub-apps within the Application.

@jaz @DakotaS96 @sdb2029 @Jacher

Does anyone have an update to if this is possible with DockerCE 2.0 and up?

I have a need for this as well, but so far I have not been successful.

I have tried copying the Docker App to the user's application folder, but that still prompts for admin credentials to configure things.

Any guidance here or update to the original workflow would be greatly appreciated!

Thanks!

These post-install commands seem to be working for me:

cp /Applications/Docker.app/Contents/Library/LaunchServices/com.docker.vmnetd /Library/PrivilegedHelperTools
cp /Applications/Docker.app/Contents/Resources/com.docker.vmnetd.plist /Library/LaunchDaemons
chown root:wheel /Library/LaunchDaemons/com.docker.vmnetd.plist /Library/PrivilegedHelperTools/com.docker.vmnetd
chmod 744 /Library/LaunchDaemons/com.docker.vmnetd.plist
launchctl load -Fw /Library/LaunchDaemons/com.docker.vmnetd.plist

I am trying to create a dmg in Composer with docker 2.3.0.3 with these instructions and can't even get the dmg to verify and mount. Current failure logs show:

Error: An error occurred attempting to mount the package "Docker 2.3.0.3.dmg".

Does anyone have any advice on this?

@tonybilzi I confirmed these commands work on version 2.3.0.4. Thank you for posting these as it saved me time trying to figure it out.

This screenshot have username so dmg will work?
Please suggest if we need to create pkg file of this.

@tonybilzi Thanks for putting up those post-install commands. Worked like a charm for 2.3.0.5

If anyone here uses AutoPkg(r), chilcote's Docker recipe adds the post install script to it automatically :)

Greetings Nation,

I was given the task to find out why docker desktop was not working/admin prompt popping up. Our devices are 1 to 1, but I am sure something like Outset could work for shared devices. The version we are using is 2.4.0.0, and it is deployed via Self-Service. The following worked in our case. I am not sure if docker has posted an "official" method. I make no guarantees, and the usual rules apply test, test, test and use at your own risk.
I did not package it but will leave a suspicious package screenshot. The team had made the package with the user similar to the above process. Well, that was problem number one. That user was not on the production Macs, so soft linking did not work.
The next problem was that they did not have a post-install script. So I grabbed the settings.json file, made the below edit to "datafolder" to blank ( it will default to the current logged in user's home folder). I dropped it in /var/tmp and made a package.
Next, I used the following script, with help from all of you. So what this does is check for "/Users/currntloggedinuser/Library/Group Containers/group.com.docker" folder. If it is not present, it creates the folder then copies the settings.json file over to "/Users/currentloggedinuser/Library/Group Containers/group.com.docker". It installs the app Package, then runs the post-install. The last step was to create a PPPC file for the desktop folder, documents folder, and reminders(?) with PPPC Utility. I will tackle updates next.

#!/bin/sh
currentUser=`stat -f "%Su" /dev/console`

/usr/bin/sudo -u $currentUser mkdir /Users/$currentUser/Library/Group Containers/group.com.docker
/usr/bin/sudo -u $currentUser cp /var/tmp/settings.json /Users/$currentUser/Library/Group Containers/group.com.docker/

sleep 5

/usr/bin/sudo defaults write /Users/$currentUser/Library/Preferences/com.docker.docker.plist SUEnableAutomaticChecks 0
/usr/bin/sudo cp /Applications/Docker.app/Contents/Library/LaunchServices/com.docker.vmnetd /Library/PrivilegedHelperTools
/usr/bin/sudo cp /Applications/Docker.app/Contents/Resources/com.docker.vmnetd.plist /Library/LaunchDaemons
/usr/bin/sudo chown root:wheel /Library/LaunchDaemons/com.docker.vmnetd.plist /Library/PrivilegedHelperTools/com.docker.vmnetd
/usr/bin/sudo chmod 744 /Library/LaunchDaemons/com.docker.vmnetd.plist
/usr/bin/sudo launchctl load -Fw /Library/LaunchDaemons/com.docker.vmnetd.plist

/usr/bin/sudo  rm -rf /var/tmp/settings.json

@efil4xiN Thanks for sharing your work on this, and the configuration script. One suggestion however - when the jamf agent is running a script the context is root, so except for where you're using sudo to run a command in the context of currentUser there is no need to prefix your commands with /usr/bin/sudo

@sdagley is correct. sometimes I get on an absolute path kick :-)

Can anyone advise on how to get the latest Docker Desktop version (v3.3.0) working without requesting admin privileges?

I tried the workflows covered above without success, I just got a prompt to reset the software to factory settings and I was then asked for administrator credentials after that process completed.

Anyone get this working for version 3.3.3? I'm in the same boat as the user post from 4/14.

Yeah, I'm also seeing this. Guessing Docker changed something...

For version 3.3.x and higher, Docker no longer bundles the .plist in the application bundle for you to copy to /Library/LaunchDaemons anymore (as per the steps above).

Some binary within the app bundle is generating this .plist now (and Docker checks for its existence on startup now, which is why you're getting the admin credentials prompt).

I haven't seen a way to call a binary to generate this file (which would be ideal), but you can grab a copy of this .plist from a successful install, and copy it to the /Library/LaunchDaemons (with correct ownership/permissions as per the steps above).

Be aware, though, that there is a <version> element in this that changes (e.g. v3.3.3 was 59, and v3.4.0 is 60), so you'll need to update your scripts pretty frequently until there's a better way.

Terms & ConditionsCookie settingsAccessibility statement