TL;DR: You gave -v something that looks like neither a valid named volume nor a bind path. Use an absolute host path for binds (`-v [HOME]/...`) or a compliant volume name (`-v mydata:/data`, matching `[a-zA-Z0-9][a-zA-Z0-9_.-]`). The parser saw `/data` alone and tried to create a volume literally named `/data`, which is illegal.

## The error

```text
docker: Error response from daemon: create /data URIs "/data" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
```

## Fix it

1. Decide: bind mount or named volume?
   - Bind: `docker run -v [HOME]/... [image]` (absolute host path, starts with /)
   - Named volume: `docker run -v mydata:/data [image]` (simple name, no slashes)
   Expected: container starts.
2. If you used a relative path like `-v data URIs/data`, that IS a named volume called "data", not ./data. Use `-v ./data URIs/data`... which also fails; use the absolute path or `$PWD/data`.

## When this applies
- `-v` with a single path or relative path
- Typos where the colon separator got lost

## When this does NOT apply
- Windows drive-letter paths (different parser failure, separate skill)
- "bind source path does not exist" (path parsed fine, dir missing)

## Versions
All Docker versions.

## Why it happens
The -v parser decides bind vs named volume by whether the source looks like a path. A bare `/data` is ambiguous-looking enough that the daemon attempts volume creation with the raw string as the name, and volume names cannot contain slashes.

## Edge cases
- `-v ~/data URIs/data` does NOT expand `~`; the shell only expands it at the start of a word. Use `$HOME/data` or the full path.
- `--mount type=bind,source=...,target=...` never has this ambiguity; prefer it in scripts.
- Volume names are limited to 255 chars in practice; long generated names hit different errors.