TL;DR: The device or host path backing the volume does not exist. Verify it with `lsblk` / `ls`, fix the device name or create the path, then retry. This hits people using the local driver's `device` option for disk-backed volumes, where a renamed disk (sdb became sdc) breaks every mount.

## The error

```text
error while mounting volume '/var/lib/docker/volumes/myvol/_data': failed to mount local volume: mount /dev/sdb1:/var/lib/docker/volumes/myvol/_data URIs no such file or directory
```

## Fix it

1. Check the device exists:
   `lsblk | grep sdb1`
   Expected: either present (path problem) or absent (device renamed/missing).
2. If the disk moved (common after reboot with multiple USB/SATA disks), find its new name and update the volume options, or better, switch the volume to UUID-based device paths.
3. If it is a plain path, create it:
   `sudo mkdir -p /mnt/voldata`
4. Retry the container start.

## When this applies
- `docker volume create --opt device=/dev/...` volumes
- Daemon/volume plugin startup failures referencing missing paths

## When this does NOT apply
- Simple bind mounts (the 'bind source path does not exist' skill)
- Permission errors on existing paths

## Versions
All Docker versions; local volume driver options are stable.

## Why it happens
The local volume driver performs a real mount syscall with your options. Unlike -v binds, there is no auto-creation; a wrong device node or missing directory fails the mount and the container never starts.

## Edge cases
- Use /dev/disk/by-uuid/... instead of /dev/sdX in volume options; sd letters are not stable across reboots.
- NFS-backed volumes (`--opt type=nfs`) fail this way when the server is unreachable; check `showmount -e [server]`.
- After fixing, `docker volume inspect myvol` shows the stored options; recreate the volume if the options themselves are wrong (options are immutable).