TL;DR: Docker tried to auto-create the bind source and the filesystem refused. Create the directory yourself somewhere writable (`mkdir -p`), or remount the filesystem read-write if it should be writable. Common triggers: paths under /usr or /System on locked-down hosts, and containers with read-only root filesystems.

## The error

```text
error while creating mount source path "/host/data": mkdir /host/data URIs read-only file system
```

## Fix it

1. Check the filesystem state:
   `mount | grep " /host "`
   Expected: shows `ro` if read-only.
2. If it should be writable, remount:
   `sudo mount -o remount,rw /host`
   Expected: no output; `mount | grep` now shows `rw`.
3. Or simply use a writable location:
   `mkdir -p [HOME]/...` and bind that instead.
4. Re-run the container.

## When this applies
- Bind sources under read-only mounts (live USB, kiosks, hardened hosts)
- macOS /System paths via Docker Desktop (SIP-protected)

## When this does NOT apply
- SELinux "permission denied" on existing dirs (label problem, separate skill)
- "bind source path does not exist" on a writable fs (just mkdir)

## Versions
All Docker versions.

## Why it happens
The -v shorthand auto-creates missing source directories via mkdir. On a read-only filesystem the mkdir fails and docker surfaces the raw error instead of proceeding.

## Edge cases
- Switch to --mount, which fails fast with 'bind source path does not exist' instead of attempting mkdir; clearer for scripts.
- On Docker Desktop Mac, the VM's filesystem layout differs from the Mac's; keep binds under /Users (shared by default).
- Read-only rootfs containers (`--read-only`) are unrelated; that flag affects the container, not the host source path.