Solveddocker sync Synchronization stops.

I use a pretty simple docker sync setup with these three files:


version: "2"
      - ./docker-config/vhost:/etc/apache2/sites-enabled/000-default.conf
      - rr-sync:/var/www/html:nocopy # nocopy is important

    external: true


version: '2'
    image: bylexus/apache-php7
      - 80:80

    image: orchardup/mysql
      - 3306:3306


version: "2"

  verbose: true
  rr-sync: # tip: add -sync and you keep consistent names as a convention
    src: './src'
    sync_excludes: ['.git']

Now it happens that the sync does start and I can visit the website on my local mashine. However when I change something nothing get's synced. When I then stop the synchronization and start the sync again with docker-sync-stack start, the latest changes are synced, but why is this not consistently the case and how I can change it?

I use MacOS Sierra 10.12.6 with the Docker version Version 17.09.0-ce-mac35 (19611) and unison sync. Thanks!

53 Answers

✔️Accepted Answer

My Specs: Sierra, raw, mac66 edge

Important, eventhough i run with raw image on Sierra, there are reports that this stuck in the start process. Maybe just upgrade to HS then

I am running mac66[edge] for 2 days now on a fairly big project and i can second that several things are changing:

TLTR: docker-sync seems to work very stable with mac66 edge for now

But there are a lot more changes:

  1. docker-compose is much more performant now and seems to have no timeouts anymore ( about 4 minute stall on commands after about 20 dc commands. This happens for anything, like dc ps or dc exec while at the same time docker ps/exec was working fine. All this thing are gone

  2. The rather big delay on shutting down a stack with CTRL+C has gone

  3. The big delay on doing dc down on bigger stack is gone

  4. the very long delay on creating service is entirely gone for bigger stack. Starts instantly as under linux

  5. The overall CPU usage on file IP like docker cp into the containers and from is significant lower

  6. The CPU usage overall seems for less laggy

  7. dc has been significanly updated including all the fixes and glitches of current linux-related stacks ( thats good for consistency )

  8. dc pull works a lot faster now, seems the same i/o benefit as seen above

Bottom line is, that mac66 edge can be really a good release for a switch. It is fixing this very issue for stopping sync but also includes significant improvments overall esp. in terms of performance

@derschatta @SilberMa @watermanio @MatthiasKuehneEllerhold please stop discussing any issue not related to docker-sync synchronization stops with post mac42 in here. I understand that you have important findings you want to share - create a new issue in docker-sync or d4m and share your insight, benchmarks and things - but stop taking the people in this issue as hostages for a different topic. I can comment on a new issue discussing in skipping docker-sync entirely, but i wont here.

Other Answers:

@EugenMayer I'm guessing the problem lies with 17.12.0-ce, which is currently the new stable.

i cannot work on those issues because all ppl give as information is 'it does' not work, fixing it by doing either nothing (just waiting), doing upgrades, some do downgrades, some do restarts

and nobody can make any sense about all this. there is litterellay no information or debuging in those reports. It's more a 'its broken, how to fix it/can somebody fix it for me'

the short answer to this is: no

Reasons vary from:

  • not reproducible on other systems and/or projects
  • way to much information is missing to make any assumption
  • no effort has been put into deducting or reducing to nail down or circle in
  • time. thats an free OSS project - get yourself involved or wait for the wonder

For example, i am running the latest docker4mac edge here:


no problems in either direction. Doing the same with the current stable, same result.
So if you expect me to magically getting involved, creating OSX VMs with your particular APFS/High Sierra and some project, you will wait forever.

Guys, take you time and finally start debugging that. You disagree on basically any matter, be it the d4m version, down or upgrading fixes it, be it a FS issue or a project issue. Get yourself a shell, use and and start acting

We did not create this for the matter of too much time - rather you getting involved and being able to help yourself when you need it most with the timeframe you are in urge or not.

But just opening a new issue after issue with "it does not work / any longer" and thats it - will not do it.

Alright I took the 20 minutes and figured it out myself. There are a couple of quick-ish ways.

The docker release notes now include links to older versions (after much arguing on github):

This 3rd party site is listing the releases:

If you know the build number you want, you can get the dmg yourself. For example, 21090 is for 17.09.1-ce-mac42 which is what I will be trying out right now to see if this fixes my issue. The URL pattern is:{{build}}/Docker.dmg

So for 21090 it is:

If you don't know the build number you want, somebody posted a handy little bash script that programmatically tries all build numbers to see if the build exists and lets you know:

for build in $(seq 21581 19125); do
  if curl -X HEAD -fsSL -I$channel/$build/Docker.dmg >/dev/null 2>/dev/null; then
    echo "Found build: $build"
    curl -X HEAD -fsSL -I$channel/$build/Docker.dmg

Change the sequence numbers on line 2 to define your range. You can set the first number to your currently broken build number (which you can find by using the menubar widget > about docker) and you can probably leave the second number alone unless you want a really old build.

I hope this helps others.

Or if you use homebrew and you want the easy way:

brew cask uninstall docker
brew cask install

The second command just installs the version of docker before the homebrew recipe was updated to include the latest, so you will still get build 21090 by doing this.

More Issues: