Fixed
The container page told people to move their data directory when their mount was simply pointing at the wrong folder.
The refusal — "there is no mount that can fix this, move DATA_DIR" — fired whenever the suggested mount point matched any destination Docksentry already has mounted. So the mount @NotRetarded added on 1 September, on my own advice, looked exactly like our data directory, and the page spent three weeks sending him after DATA_DIR instead of telling him his source was wrong.
Worse: the suggestion it threw away was right. Docksentry asks the daemon which container actually holds that Compose file, so the correct source was already computed — and then replaced with advice about DATA_DIR.
The refusal now measures against the real data directory, which is the case it was written for: /data is ours and Portainer's, and a mount landing there would hide our state. Three situations, three sentences:
| would cover our data directory | unchanged: move DATA_DIR first
|
| already mounted there, file still missing | names what you mount, and which source the daemon says holds the file |
| nothing mounted | the volume line, as before |
The page, /audit and the update note all decide it the same way, so none of them can disagree about a container.
178 procedures, 4094 checks.