Ошибка volumes myvolume is not a valid volume mount point появляется при запуске контейнера через docker-compose up или docker run, когда Docker не может интерпретировать указанный том как корректную точку монтирования. Чаще всего причина кроется в синтаксисе секции volumes в файле docker-compose.yml: отсутствует двоеточие между именем тома и путём внутри контейнера, используются недопустимые символы или том не объявлен на верхнем уровне файла.
Проблема блокирует запуск всего стека, поэтому контейнер не стартует вовсе — зависимые сервисы тоже останавливаются. Хорошая новость в том, что ошибка почти всегда связана с конфигурацией, а не с повреждением данных, и исправляется правкой compose-файла за несколько минут. Ниже разберём типовые причины, порядок диагностики и безопасные способы исправления.
Что означает эта ошибка
Docker ожидает, что каждая запись в секции volumes сервиса будет соответствовать одному из допустимых форматов: имя_тома:путь_в_контейнере для именованных томов или ./локальный_путь:/путь_в_контейнере для bind-монтирования. Если строка не поддаётся разбору — например, в ней просто написано myvolume без двоеточия и целевого пути — движок отклоняет её с сообщением о невалидной точке монтирования.
Важно понимать разницу между именованным томом и bind mount. Именованный том управляется самим Docker и хранится в его внутренней директории, а bind mount связывает контейнер с конкретной папкой на хосте. Синтаксис у них похож, но требования к написанию различаются, и путаница между ними — частый источник сбоя.
Типичные причины ошибки
Перед исправлением полезно понять, какая именно из причин применима к вашему случаю. Ниже перечислены сценарии, которые встречаются чаще всего.
- 📌 В секции
volumesсервиса указано только имя тома без целевого пути:- myvolumeвместо- myvolume:/data. - 📝 Том
myvolumeне объявлен в верхнеуровневой секцииvolumes:compose-файла. - 🔤 В имени тома используются недопустимые символы — пробелы, заглавные буквы в некоторых контекстах, спецсимволы.
- 🗂️ Относительный путь bind-монтирования указывает на несуществующую директорию или содержит опечатку.
- 🧩 Ошибки отступов в YAML: запись попала не в ту секцию или сместилась по уровню вложенности.
Отдельно стоит упомянуть смешение синтаксисов. Если вы скопировали фрагмент из чужого примера, где использовался длинный формат type: volume с ключами source и target, а затем частично переписали его в короткий, результатом может стать гибридная строка, которую Docker не распознаёт.
Как проверить конфигурацию
Первый шаг диагностики — валидация compose-файла встроенными средствами. Команда ниже покажет итоговую конфигурацию после подстановки переменных и укажет на синтаксические проблемы:
docker compose configЕсли файл содержит ошибки YAML-структуры, команда сообщит об этом с указанием строки. Если конфигурация валидна, вы увидите полное развёрнутое описание стека — сверьте секцию volumes проблемного сервиса с ожидаемой.
Второй шаг — проверить, существует ли именованный том и корректно ли он создан:
docker volume ls
docker volume inspect myvolume
Если том отсутствует в списке, но должен создаваться автоматически — убедитесь, что он объявлен в верхнеуровневой секции volumes: compose-файла. Без этого объявления Compose попытается трактовать запись как путь на хосте, что и приводит к ошибке валидации точки монтирования.
⚠️ Внимание: не удаляйте существующие тома командой docker volume rm «для чистки», пока не убедитесь, что в них нет нужных данных. Удаление тома необратимо — данные базы или загруженные файлы будут потеряны.
Пошаговое исправление в docker-compose.yml
Откройте docker-compose.yml и приведите секцию монтирования к корректному виду. Рабочий минимальный пример для именованного тома выглядит так:
services:
app:
image: myimage
volumes:
- myvolume:/var/lib/app
volumes:
myvolume:
Обратите внимание на два обязательных элемента. Внутри сервиса запись содержит двоеточие: слева — имя тома, справа — абсолютный путь внутри контейнера. А на верхнем уровне файла том явно объявлен в секции volumes:, даже если после имени нет дополнительных параметров.
Для bind-монтирования локальной папки синтаксис иной:
volumes:
- ./data:/var/lib/app
Здесь слева от двоеточия — путь на хосте (относительный или абсолютный), справа — путь в контейнере. Убедитесь, что директория ./data существует относительно расположения compose-файла, либо создайте её заранее.
☑️ Проверка перед повторным запуском
После правок перезапустите стек:
docker compose down
docker compose up -d
Особенности для docker run и разных ОС
При запуске через docker run аналогичная ошибка возникает при неверном флаге -v. Корректный формат:
docker run -v myvolume:/data myimageЕсли вы случайно написали -v myvolume без целевого пути, Docker отклонит запуск. То же произойдёт при смешении флагов -v и --mount с несовместимыми параметрами.
На Windows добавляется нюанс с путями: обратные слеши и буквы дисков в bind-монтировании могут требовать особого экранирования в зависимости от терминала. В PowerShell и Git Bash поведение различается, поэтому при проблемах с путями проверьте документацию Docker Desktop для вашего окружения. На macOS и Linux дополнительно проверяйте права доступа к монтируемой директории — хотя ошибка прав обычно выглядит иначе, она может маскироваться под проблему монтирования.
⚠️ Внимание: при смене записи с bind mount на именованный том (или наоборот) старые данные не переносятся автоматически. Если в контейнере хранилась база данных, сначала сделайте резервную копию, иначе после пересоздания контейнера вы увидите пустое хранилище.
Сравнение подходов к монтированию
| Критерий | Именованный том | Bind mount |
|---|---|---|
| Управление хранилищем | Движком Docker | Пользователем вручную |
| Типичный синтаксис | myvolume:/data |
./data:/data |
| Требование объявления в compose | Да, в секции volumes верхнего уровня | Нет |
| Подходит для | Базы данных, персистентные данные | Код, конфиги при разработке |
| Частая ошибка | Пропущено объявление тома | Неверный или несуществующий путь |
Выбор между подходами влияет и на диагностику: для именованного тома проверяйте его наличие через docker volume ls, а для bind mount — существование папки на хосте и корректность относительного пути относительно расположения compose-файла.
Как посмотреть, куда смонтирован том в работающем контейнере
Выполните docker inspect имя_контейнера и найдите секцию Mounts — там будут поля Source (источник на хосте) и Destination (путь в контейнере). Это помогает убедиться, что монтирование произошло именно так, как задумано.
Что делать, если ошибка осталась
Если после правки синтаксиса ошибка сохраняется, проверьте версию используемых инструментов. Старые версии docker-compose (v1, с дефисом) и новый плагин docker compose (v2, без дефиса) могут по-разному трактовать некоторые конструкции. Уточните, какая версия установлена, командой docker compose version, и сверьтесь с документацией именно для неё.
Также осмотрите файл на предмет невидимых символов: скопированные из веб-страниц фрагменты иногда содержат неразрывные пробелы или табуляцию вместо пробелов, что ломает разбор YAML. Надёжный способ — удалить проблемный блок и набрать его заново вручную.
Наконец, убедитесь, что запуск происходит из той директории, где лежит нужный compose-файл, либо что путь к файлу задан явно через флаг -f. Docker может подхватывать другой docker-compose.yml из текущей папки, и вы будете править один файл, а запускаться — другой.
Частые вопросы
Можно ли использовать заглавные буквы в имени тома?
Имена томов Docker имеют ограничения на допустимые символы. Рекомендуется придерживаться строчных букв, цифр, дефисов и подчёркиваний — это исключает проблемы с валидацией и переносимостью между окружениями.
Чем отличается docker-compose от docker compose?
docker-compose — отдельная утилита первой версии, а docker compose — встроенный плагин Docker второй версии. Вторая версия актуальна и рекомендована; синтаксис команд в основном совпадает, но поведение в отдельных случаях может различаться.
Потеряются ли данные при исправлении compose-файла?
Нет, если вы не удаляете сам том. Именованный том хранится отдельно от контейнера: правка файла и пересоздание контейнера командой docker compose up -d сохраняют данные, если имя тома не изменилось.
Ошибка появляется только на сервере, локально всё работает. Почему?
Возможные причины: другая версия Docker или Compose на сервере, отсутствие директории для bind-монтирования, различия в относительных путях из-за другой рабочей директории. Сравните вывод docker compose config на обеих машинах.
Как полностью пересоздать том с нуля?
Остановите стек командой docker compose down, затем при необходимости удалите том: docker volume rm myvolume. При следующем запуске том будет создан заново, но все прежние данные в нём будут утеряны — предварительно сделайте резервную копию.