How to fix Error response from daemon: No such volume: myvolume in Docker

DockerBEGINNERMEDIUM

The 'No such volume' error occurs when Docker cannot find a named volume you're trying to use or reference. Create the volume first, check for typos in the volume name, or use bind mounts if you intended to mount a host directory.

What this error means

The "No such volume" error in Docker indicates that the Docker daemon cannot locate a named volume with the specified name. This typically happens when you try to run a container, inspect, or remove a volume that doesn't exist in Docker's volume registry. Docker volumes are managed storage units that persist data independently of containers. Unlike bind mounts (which reference host directories directly), named volumes must be explicitly created before use in most scenarios. When Docker can't find a volume by name, it throws this error to prevent silent failures. This error can also occur when the volume name is misspelled, when working across different Docker contexts (like switching between local and remote Docker hosts), or when Docker Desktop's internal state becomes inconsistent after upgrades or crashes.

How to fix "Error response from daemon: No such volume: myvolume"

1Verify the volume doesn't exist

First, confirm which volumes currently exist on your Docker host:

bash

# List all volumes
docker volume ls

# Search for a specific volume (partial match)
docker volume ls --filter name=myvolume

# Get detailed information about a volume
docker volume inspect myvolume

If your volume isn't in the list, you'll need to create it or correct the volume name in your command.

2Create the missing volume

If the volume doesn't exist yet, create it explicitly:

bash

# Create a basic named volume
docker volume create myvolume

# Create with specific driver options
docker volume create --driver local \
  --opt type=none \
  --opt device=/path/on/host \
  --opt o=bind \
  myvolume

# Verify it was created
docker volume ls | grep myvolume

After creating the volume, retry your original command:

bash

docker run -v myvolume:/data myimage

3Check for typos in the volume name

Volume names are case-sensitive and must match exactly. Compare your command with existing volumes:

bash

# List all volumes to check spelling
docker volume ls --format "{{.Name}}"

# Common mistakes to check:
# - myVolume vs myvolume (case sensitivity)
# - my_volume vs my-volume (underscores vs hyphens)
# - myvolume vs my_volume (missing separator)

If you find the correct name, update your command or create an alias:

bash

# If the volume exists with a different name, use the correct name
docker run -v correct_volume_name:/data myimage

4Fix Docker Compose external volume declaration

If you're using Docker Compose with an external volume, the volume must exist before running docker compose up:

yaml

# docker-compose.yml
volumes:
  myvolume:
    external: true  # Requires pre-existing volume

Create the external volume first:

bash

# Create the volume
docker volume create myvolume

# Then start your compose stack
docker compose up

Alternatively, remove external: true to let Compose create the volume automatically:

yaml

volumes:
  myvolume:
    # No 'external: true' - Compose will create this

5Check if you meant to use a bind mount

A common source of confusion is the difference between named volumes and bind mounts:

bash

# Named volume (Docker manages storage) - requires volume to exist
docker run -v myvolume:/data myimage

# Bind mount (host directory) - path must start with / or ./
docker run -v /host/path:/data myimage
docker run -v ./local/path:/data myimage

If you intended to mount a host directory, add the path prefix:

bash

# Use absolute path for bind mount
docker run -v /home/user/mydata:/data myimage

# Use relative path (current directory)
docker run -v "$(pwd)/mydata:/data" myimage

# Or using the --mount syntax for clarity
docker run --mount type=bind,source=/host/path,target=/data myimage

Key difference: Without a leading / or ./, Docker interprets the source as a volume name, not a path.

6Restore volumes after Docker Desktop upgrade

If volumes disappeared after a Docker Desktop upgrade, they may still exist on disk but not be registered:

On Windows (WSL2 backend):

bash

# Check if volume data still exists
ls "\\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes"

On macOS:

bash

# Access Docker VM to check volumes
docker run -it --rm --privileged --pid=host alpine nsenter -t 1 -m -u -n -i sh
ls /var/lib/docker/volumes

If data exists but volumes aren't visible:

1. Restart Docker Desktop completely
2. Try running docker volume ls again
3. If still missing, you may need to manually recreate volumes and restore data

Important: Back up any recovered data before attempting repairs.

7Check Docker context for remote hosts

If you're using Docker contexts to manage multiple Docker hosts, the volume may exist on a different host:

bash

# Show current context
docker context show

# List all contexts
docker context ls

# Switch to a different context
docker context use default

# List volumes in the current context
docker volume ls

If your volume exists in a different context, either:
- Switch to that context: docker context use <context-name>
- Create the volume in your current context
- Specify the context explicitly: docker --context <name> volume ls

Advanced notes

### Named Volumes vs Bind Mounts

Understanding when Docker treats a mount source as a volume name vs a host path is critical:

| Source Format | Type | Behavior |
|--------------|------|----------|
| myvolume:/data | Named Volume | Docker looks up volume by name |
| /host/path:/data | Bind Mount | Docker mounts host directory |
| ./relative:/data | Bind Mount | Docker mounts relative to compose file |
| ~/home:/data | Bind Mount | Docker expands ~ to home directory |

### Docker Compose Volume Lifecycle

In Docker Compose, volumes have different behaviors based on configuration:

yaml

volumes:
  # Compose creates and manages this volume
  managed_volume:

  # Must exist before 'docker compose up'
  external_volume:
    external: true

  # External with different name
  aliased_volume:
    external: true
    name: actual_volume_name

Use docker compose down -v to remove Compose-managed volumes, but note that external volumes are never removed by Compose.

### Volume Naming with Project Prefix

Docker Compose prefixes volume names with the project name by default:

bash

# If your project is "myapp" and volume is "data"
# The actual volume name becomes: myapp_data

docker volume ls
# DRIVER    VOLUME NAME
# local     myapp_data

To avoid this, use name: to specify the exact name:

yaml

volumes:
  data:
    name: data  # Exactly "data", no prefix

### Recovering Accidentally Pruned Volumes

If you ran docker volume prune or docker system prune and lost important data, recovery options are limited:

1. Immediate: Stop all Docker operations to prevent data overwrite
2. Professional recovery: Third-party data recovery tools may help on the underlying storage
3. Prevention: Use --filter with prune commands to protect specific volumes:

bash

# Only prune volumes not matching a pattern
docker volume prune --filter "label!=keep"

### Volume Driver Issues

If using a volume driver plugin (e.g., for cloud storage), the "No such volume" error might indicate driver issues:

bash

# Check volume driver status
docker plugin ls

# Enable a disabled driver
docker plugin enable <plugin-name>

# View driver logs
docker plugin inspect <plugin-name>

How to fix Error response from daemon: No such volume: myvolume in Docker

What this error means

Typical symptoms

Common causes

How to fix "Error response from daemon: No such volume: myvolume"

Advanced notes

Related errors

Official resources & further reading