mountInotify: chmod inside the container is sometimes reverted #1647

Description

Hi, and thanks for Colima — we use it daily for Buildroot builds on macOS.

With mountInotify enabled, files on a bind mount occasionally lose a mode change made inside the container. The chmod succeeds, but a moment later the file is back to the mode it was created with (e.g. 0644 instead of 0755). In our builds this left init scripts without the execute bit.

Looking at daemon/process/inotify, it seems to be a race: the watcher reads the file's mode on the host (watch.go), and the event handler later runs chmod <that mode> in the guest (events.go). If the container changes the mode in between, the guest chmod puts the old one back. The same code is still on master.

Version

colima version 0.10.3
git commit: 00f6c297e92a82c04a4ab507db0a61435650d7e8

runtime: docker
arch: aarch64
client: v29.8.2
server: v29.2.1
limactl version 2.2.1

qemu-img is not installed (vz only).

Operating System

• macOS Intel <= 13 (Ventura)
• macOS Intel >= 14 (Sonoma)
• Apple Silicon <= 13 (Ventura)
• Apple Silicon >= 14 (Sonoma)
• Linux

Output of colima status

INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs

Reproduction Steps

1. colima start --vm-type vz --mount-type virtiofs --mount <dir>:w --mount-inotify
2. In a container that bind-mounts <dir>, run a few parallel loops of echo x > f$i && chmod 755 f$i, while something else writes large files to the same mount.
3. find <dir> -type f ! -perm 755

Expected behaviour

Every file keeps mode 755. We got about 1 in 30,000 back at 0644, each with a syncing inotify event line in daemon.log. With --mount-inotify=false, none.

Additional context

Maybe the guest step could trigger the event without applying a mode read earlier, e.g. just the : >> path from #1643? macOS 27.0.1.