Docker bind mount vs cloud data disk race destroys data

Classic production trap: on cloud VMs (Azure, AWS, etc.) with data disks mounted via systemd at /mnt/data, if Docker starts before systemd finishes the disk mount, every container with a bind mount to /mnt/data/<x> captures the inode of the EMPTY underlay directory on the OS root filesystem. The disk then mounts on top of /mnt/data, hiding the OS-disk underlay from the host shell — but the container keeps writing to the OS-disk path because its bind mount was resolved at container-create time, not at access time. Symptoms: apps act like fresh installs (postgres re-runs initdb, sqlite-backed apps show admin-setup wizards, JSON-store apps come up empty). The REAL data is still intact on the data disk, just shadowed. Detection in 2 seconds: stat -c%i <host path> vs docker exec <container> stat -c%i <container path>. If inodes differ, the race fired and you are writing to the wrong filesystem. Recovery: docker rm + docker compose up to re-resolve the bind mount against the now-mounted disk. Prevention: add x-systemd.before=docker.service to the disk mount in /etc/fstab, OR make docker.service depend on the mount unit explicitly, OR use a startup script that runs mountpoint -q /mnt/data && docker compose up instead of letting Docker race the mount.