TL;DR: Create the host directory first (`mkdir -p /host/data`), then re-run. Unlike named volumes, bind mounts require the source path to exist; docker will not create it for you with --mount (and -v only auto-creates directories, not files, and with root ownership that causes its own problems).

## The error

```text
invalid mount config for type "bind": bind source path does not exist: /host/data
```

## Fix it

1. Create the path on the host:
   `mkdir -p /host/data`
   Expected: no output.
2. Fix ownership if the container runs as non-root:
   `sudo chown -R 1000:1000 /host/data`
   Expected: container user can write.
3. Re-run the container.

## When this applies
- `--mount type=bind` with a missing source (strict: always fails)
- `-v` bind of a specific FILE that does not exist (creates a directory instead, then the app fails weirdly)

## When this does NOT apply
- Named volumes (docker creates those automatically)
- "permission denied" writing to an existing bind (ownership/SELinux, separate skill)

## Versions
All Docker versions. --mount has always been strict; -v auto-creates missing source DIRS.

## Why it happens
--mount validates the source before creating the container and refuses to guess. The -v shorthand is lenient for directories but that leniency backfires for files: `-v /host/app.conf:/etc/app.conf` with a missing file creates a DIRECTORY at /host/app.conf, and the app then fails to read its "config file".

## Edge cases
- Prefer --mount in scripts precisely because it fails fast instead of creating wrong-typed paths.
- Docker Desktop file sharing: the path must also be shared (Settings > Resources > File Sharing) or the bind appears empty.
- Symlinked source paths resolve on the host; a dangling symlink gives this error.