File change is only registered if change happens within the container

silend commented 1 year ago

[x] I have tried with the latest version of Docker Desktop
[x] I have tried disabling enabled experimental features
[ ] I have uploaded Diagnostics
Diagnostics ID:

Expected behavior

When a file in a mounted folder is changed on the host, file watchers (eg. nodemon) running inside the container should register that change.

Actual behavior

The container only reflects the file change from host on restart. However, when the file is changed from inside the container (eg. touch [file]) watching processes (eg. nodemon) register the file change and behave as expected.

Information

I have recently switched from Docker Engine to Docker Desktop and noticed the problem with an existing project, that was working before on Docker Engine / docker-compose (version 1).

The problem is reproducible and showing consistently, also when using a fresh example from Docker docs.

Docker Engine and docker-compose (version 1) was fully deinstalled before installing the latest version of Docker Desktop according to the instructions.

To reproduce:

Create package.json inside an empty directory with the following content:

{
  "name": "docker-mount",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "devDependencies": {},
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "nodemon"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "nodemon": "^2.0.20"
  }
}

Add index.js with the following content:

console.log('hello');

Run the following command

docker run -dp 3000:3000 \
     -w /app -v "$(pwd):/app" \
     node:12-alpine \
     sh -c "yarn install && yarn run dev"

When index.js is now changed on the host (eg. with VS Code), nodemon does not restart within the container.

If going inside the container using docker exec -it [containerID] sh and using touch index.js the node process is restarted.

It is not only an issue with nodemon. In my project it behaves the same way also with nuxt.

What is weird: After updating a file on the host, using stat [filename] shows the same size and modification date on both the host and inside the container, however the watching processes seem to be blind to this change.

Linux distro: Pop!_OS / Ubuntu
Distro version: 22.04 LTS
Docker Desktop Version:

docker version

Client: Docker Engine - Community
 Cloud integration: v1.0.29
 Version:           20.10.18
 API version:       1.41
 Go version:        go1.18.6
 Git commit:        b40c2f6
 Built:             Thu Sep  8 23:11:43 2022
 OS/Arch:           linux/amd64
 Context:           desktop-linux
 Experimental:      true

Server: Docker Desktop 4.12.0 (85629)
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:23 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.10.2)
  extension: Manages Docker extensions (Docker Inc., v0.2.9)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.19.0)

Server:
 Containers: 9
  Running: 9
  Paused: 0
  Stopped: 0
 Images: 12
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.124-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.672GiB
 Name: docker-desktop
 ID: W4B2:IPH2:PLDZ:72CB:QAC6:3T2E:ABSK:6HEQ:2CIN:VNEU:WOJK:WM22
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

silend commented 1 year ago

Update: I've just tested it on a fresh install of Pop!_OS 22.04 LTS / Ubuntu and it shows the same issue as described above.

The only things that were installed other than docker-desktop-4.12.0-amd64 (and setting up the repository as described here but not installing anything myself, rather let Docker Desktop install the Docker Engine) were:

zsh and Oh My Zsh
nvm and latest Node.js LTS v16.17.1
VS Code
1Password

Other than that the system is vanilla and shows the issue described here, so it is safe to say that the issue is not coming from a previously installed version of Docker Engine or docker-compose.

silend commented 1 year ago

Update: Made more tests on macOS 11.6 and vanilla installations of Ubuntu 22.04 LTS (not Pop!_OS)

macOS 11.6 using latest version of Docker Desktop: :heavy_check_mark: It works as expected and does not show the issue.

Ubuntu 22.04 with latest docker-ce from https://download.docker.com/linux/ubuntu jammy/stable amd64: :heavy_check_mark: It works as expected and does not show the issue.

Ubuntu 22.04 with latest Docker Desktop from https://docs.docker.com/desktop/install/linux-install/: :negative_squared_cross_mark: Does show described issue.

I read from these testings that it is not a general Docker (Engine) issue, and also not caused by Docker Desktop behaving differently than Docker Engine, as the macOS version behaves as expected. The issue only shows in the (Ubuntu?) Linux version of Docker Desktop.

richard5mith commented 1 year ago

I am seeing the same issue on Docker Desktop with Ubuntu 22.04. But I have three separate projects, all of which use essentially the same Docker setup, and only 1 of them is experiencing the issue.

The same project run through Docker Engine, without Docker Desktop, on a colleagues Linux works fine.

ryan-cahill commented 1 year ago

I've had a very similar issue since switching from Docker CE to Docker Desktop as well: https://github.com/docker/desktop-linux/issues/30. My workaround was to use polling to watch the file changes.

docker-robott commented 1 year ago

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 30 days.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

docker-robot[bot] commented 1 year ago

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 30 days.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

docker / desktop-linux