docker: Error response from daemon: create /data URIs "/data" includes invalid characters for a local volume name

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

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.

1. 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.