Hot reloading is not triggered after upgrading to Docker Desktop

[ryan-cahill]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 53e86c34-6518-444f-a08a-ca1848b241f7/20220617214149

Expected behavior

Hot reloading works for containers when a volume is shared between the host and the container.

Actual behavior

File changes can be seen between the host and the container as expected, however, no hot reloading occurs in any framework.

Information

• Linux distro: 22.04 LTS
• Distro version: Ubuntu
• Docker Desktop Version: 4.9.1 (81317)

Steps to reproduce the behavior

1. Clone the repo at https://github.com/ryan-cahill/nuxt-test-app
2. Navigate to the cloned repo's directory root and run docker build . -t nuxt-reload && docker run -it -p 0.0.0.0:3000:3000 -v $(pwd)/src:/usr/src/app/src --name nuxt-reload nuxt-reload to build and run the Docker container.
3. On your local machine, modify any vue file in the app, for example src/pages/index.vue.
4. Run docker exec -it nuxt-reload sh to exec into the container, then when in the container, run cat /usr/src/app/src/pages/index.vue and notice that your file changes have taken effect.
5. Notice that the app hasn't hot reloaded in either the terminal or in your browser. If for example you just ran the app with npm run dev on your host, the app would hot reload when file changes are made. After installing Docker Desktop for Linux, hot reloading no longer works for any application of mine that I run inside of Docker.
6. Please let me know if I can provide any more information, tests, context, etc.

[billytetrud]

I have also noticed this. I'm on Kubuntu 22 (lsb_release -a gives Ubuntu 18.04.6 LTS), Docker Desktop 4.10.1 (82475). inotifywait in a container does not receive notifications when the host modifies the file (only when the file is modified guest-side). This is a huge problem for edit refresh development.

[billytetrud]

I downgraded to 20.10.14 and it solved my problem.

[bessiambre]

I'm also on Ubuntu 22.04 LTS. I couldn't figure this out with latest Docker Desktop running Docker engine 20.10.17. I switched away from Docker Desktop to using the native Docker Engine instead (latest version 20.10.18) and it seems to fix the problem.

[faizjamil]

Hot reload (called HMR on Next.js's site) doesn't work with Next.js (v12) apps either. Experienced this with a Next.js codebase I work on at my job. In addition I just made a new Next.js app using create-next-app, Dockerized it and reproduced the issue of hot reload not working. Might go back to Docker CE, with the various problems with permissions and a bug in the MySQL image that will bring.

[agiangrant]

Experiencing the same issue with desktop on Linux Mint 21. It's an obvious decision to switch back to Docker Engine since dev server restarts from the host are just not possible at this time (without changing how the file watch is happening in the dev server).

I investigated some workarounds. Docker Engine, containerd, runc, and compose are all independent of the desktop meaning I can run the exact same versions without desktop and it works. There are a couple of internal settings in ~/.docker/desktop/settings.json but I believe it's all about the context and how and where it's run.

Docker engine without desktop will run the "default" context. If you have Docker Desktop installed, run docker context ls and you'll see what I mean. There is no way to control how the "linux-desktop" context is created. If you switch the ~/.docker/config.json's current context to "default" it works but it will overwrite the context every time Docker Desktop starts up. Oh, but then you could just change the metadata for the context so it works properly? No, Docker Desktop will remove its last context and generate a new one every time it restarts, and your changes are lost. Just change the context to "default"? No, Docker desktop will change the context back on startup. Even if you add a docker context use default to your .profile (or .bashrc or whatever you use). None of the containers that are run in the default context show up in Docker Desktop.

[p1-0tr]

Hi, thanks for filing this issue and sorry for the inconvenience. We are looking into improving how file sharing between the host and Docker Desktop's VM is implemented, one of which is adding inotify support.

[p1-0tr]

Hi, thanks for your patience.

@ryan-cahill, @billytetrud, @bessiambre, @faizjamil, @agiangrant - Below I've posted links to a dev build with inotify fixes for Linux. Let me know if this resolves issues you've been experiencing.

• https://desktop-stage.docker.com/linux/main/amd64/91547/docker-desktop-4.15.0-amd64.deb
• https://desktop-stage.docker.com/linux/main/amd64/91547/docker-desktop-4.15.0-x86_64.rpm
• https://desktop-stage.docker.com/linux/main/amd64/91547/docker-desktop-4.15.0-x86_64.pkg.tar.zst

[faizjamil]

@p1-0tr got any tips for how to use docker desktop alongside docker engine? I would prefer to not have to rebuild and resetup my containers for work.

[p1-0tr]

@faizjamil Docker Desktop and Engine are largely independent. You can run both on the same system, and switch based on the Docker CLI context, but remember that Docker Desktop will change the CLI context to its own every time it starts. E.g. assuming a default installation of Engine and Desktop you should have two contexts default and desktop-linux, so to switch to the Engine you'd do docker context use default and to switch to Desktop docker context use desktop-linux (see https://docs.docker.com/engine/context/working-with-contexts/ for more details).

[faizjamil]

@p1-0tr

Testing this quickly I found that hot reload on Next.js now works. Thanks!

[maxcleme]

Closing this issue because a fix has been released in Docker Desktop 4.15.0. See release notes for more details.