Mounting folder on windows into docker container #12673

Comments

tomitrescak commented Apr 23, 2015

Hi, I search rigidly for the solution to the obvious problem, but cannot find it.
I am trying to mount a folder from my host (windows 8.1) into my docker containers folde ‘/mnt/src’.

Running following command produces error:

$ docker run -v /c/Users/Tomi/src:/mnt/src tomitrescak/meteor
invalid value «c:\Users\Tomi;C:\Program Files (x86)\Git\mnt» for flag -v: \Users\Tomi;C:\Program Files (x86)\Git\mnt is not an absolute path

The text was updated successfully, but these errors were encountered:

ghost commented Apr 23, 2015

Any command you send to the Docker daemon is relative to the server it’s running on. As in you can not mount a local directory or file to a remote container. The limitation is being worked on with projects like Flocker to allow volumes and containers to be shared across hosts.

cpuguy83 commented Apr 23, 2015

As @usertaken said, you cannot mount folders from a different machine into the container.
If you are using boot2docker + virtualbox you may be able to share folders with the boot2docker VM and mount them into the container that way.

Closing since this is a non-issue.

tomitrescak commented Apr 23, 2015

Ok, I misunderstood the concept then. Sorry. If would spare a little help, how can I copy files to to VM then and access them from the host then? Thanks. I will write a blogpost so that other lame people won’t have to deal with it anymore.

mlapierre commented Apr 27, 2015

@tomitrescak it looks like you’re using msys or cygwin. Try //c/Users instead of /c/Users eg:

docker run -v //c/Users/Tomi/src:/mnt/src tomitrescak/meteor

Alternatively, use Powershell or cmd.exe

eliezeralmeida commented Dec 9, 2015

@mlapierre It worked to me. Thank you!

vgoncharenko commented Oct 4, 2016

Also help replace all ‘/’ to ‘//’.
//c//Users//Tomi//src://mnt//src tomitrescak//meteor

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Docker can’t mount folder on Windows

I can’t mount a folder on Docker on Windows. I’m using the repository https://github.com/LaraDock/laradock. In docker-compose.yml , line 23, there is a folders mapping:

In the VirtualBox folder, D:\VM is shared. When I start the container and list files there is just the laradock folder, but I have a whole Laravel installation in that folder that should be, but isn’t listed.

When I try to mount from inside the machine, I get permission denied:

When I try to bind from Docker it is silent, but the folder isn’t mounted, and files aren’t listed.

Here is debug information for a container that defines volume mapping:

2 Answers 2

When using Docker Toolbox, it is a two-step process to mount a folder to a container. On Windows/OS X, Docker runs inside a VirtualBox VM. First, you need to mount your Windows/OS X folder to VirtualBox. Second, you can then mount the VirtualBox folder to Docker using volumes. Docker does not have access to your Windows/OS X folders except the User folder (which is because the VirtualBox VM mounts that folder to the VM by default)

If you mounted your D:/VM folder to /d/vm on the virtual machine, then you can change the volumes section of your Docker Compose file to — /d/vm/zemke2/laradock:/var/www/laravel

For those who are using Docker for Windows (on Hyper-V):

If you experience this issue when using Laradock or any other container, please make sure you select your drives under Shared Drives and add the credentials of a user with access to those same drives. Some people also have experienced this same issue when their passwords contain spaces or special characters. It’s also worth noting that you should add your username like this: hostip\username

Another possible solution would be to temporarily disable your firewall and restarting Docker. I’ve seen this as being a more popular cause of Docker not being able to view project folders/filers. You’d need allow communication to/from the docker IP address, or better yet, change the policy of the virtual network adapter to one where sharing files/printers is allowed (i.e Private Network — this mainly depends of your own settings).

For even more solutions you might want to visit the Docker forums. This thread in particular contains heaps of other possible solutions, as this is a very common issue in the Windows environment.

How to mount network Volume in Docker for Windows (Windows 10)

We’re working to create a standard «data science» image in Docker in order to help our team maintain a consistent environment. In order for this to be useful for us, we need the containers to have read/write access to our company’s network. How can I mount a network drive to a docker container?

Here’s what I’ve tried using the rocker/rstudio image from Docker Hub:

docker run -d -p 8787:8787 -v //c/users/:/home/rstudio/foobar rocker/rstudio

This does not work (where P is the mapped location of the network drive): docker run -d -p 8787:8787 -v //p:/home/rstudio/foobar rocker/rstudio

This also does not work: docker run -d -p 8787:8787 -v //10.1.11.###/projects:/home/rstudio/foobar rocker/rstudio

I’m relatively new to Docker, so please let me know if I’m not being totally clear.

4 Answers 4

I know this is relatively old — but for the sake of others — here is what usually works for me. for use — we use a windows file-server so we use cifs-utils in order to map the drive. I assume that below instructions can be applied to nfs or anything else as well.

first — need to run the container in privileged mode so that you can mount remote folders inside of the container ( —dns flag might not be required)
docker run —dns -p 8000:80 —privileged -it

now, (assuming centos with cifs and being root in the container) — hop into the container and run:

install cifs-utils if not installed yet
yum -y install cifs-utils

create the local dir to be mapped
mkdir /mnt/my-mounted-folder

prepare a file with username and credentials
echo «username= » >

/.smbcredentials
echo «password=

map the remote folder
mount -t cifs -o iocharset=utf8,credentials=/root/.smbcredentials,file_mode=0777,dir_mode=0777,uid=1000,gid=1000,cache=strict

Хранение данных в Docker

Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.

В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.

Особенности работы контейнеров

Прежде чем перейти к способам хранения данных, вспомним устройство контейнеров. Это поможет лучше понять основную тему.

Контейнер создаётся из образа, в котором есть всё для начала его работы. Но там не хранится и тем более не изменяется ничего важного. В любой момент приложение в контейнере может быть завершено, а контейнер уничтожен, и это нормально. Контейнер отработал — выкидываем его и собираем новый. Если пользователь загрузил в приложение картинку, то при замене контейнера она удалится.

На схеме показано устройство контейнера, запущенного из образа Ubuntu 15.04. Контейнер состоит из пяти слоёв: четыре из них принадлежат образу, и лишь один — самому контейнеру. Слои образа доступны только для чтения, слой контейнера — для чтения и для записи. Если при работе приложения какие-то данные будут изменяться, они попадут в слой контейнера. Но при уничтожении контейнера слой будет безвозвратно потерян, и все данные вместе с ним.

В идеальном мире Docker используют только для запуска stateless-приложений, которые не читают и не сохраняют данные о своём состоянии и готовы в любой момент завершиться. Однако в реальности большинство программ относятся к категории stateful, то есть требуют сохранения данных между перезапусками.

Поэтому нужны способы сделать так, чтобы важные изменяемые данные не зависели от эфемерности контейнеров и, как бонус, были доступными сразу из нескольких мест.

В Docker есть несколько способов хранения данных. Наиболее распространенные:

• тома хранения данных (docker volumes),
• монтирование каталогов с хоста (bind mount).

Особые типы хранения:

• именованные каналы (named pipes, только в Windows),
• монтирование tmpfs (только в Linux).

На схеме показаны самые популярные типы хранения данных для Linux: в памяти (tmpfs), в файловой системе хоста (bind mount), в томе Docker (docker volumes). Разберём каждый вариант.

Тома (docker volumes)

Тома — рекомендуемый разработчиками Docker способ хранения данных. В Linux тома находятся по умолчанию в /var/lib/docker/volumes/. Другие программы не должны получать к ним доступ напрямую, только через контейнер.

Тома создаются и управляются средствами Docker: командой docker volume create, через указание тома при создании контейнера в Dockerfile или docker-compose.yml.

В контейнере том видно как обычный каталог, который мы определяем в Dockerfile. Тома могут быть с именами или без — безымянным томам Docker сам присвоит имя.

Один том может быть примонтирован одновременно в несколько контейнеров. Когда никто не использует том, он не удаляется, а продолжает существовать. Команда для удаления томов: docker volume prune.

Можно выбрать специальный драйвер для тома и хранить данные не на хосте, а на удалённом сервере или в облаке.

Для чего стоит использовать тома в Docker:

• шаринг данных между несколькими запущенными контейнерами,
• решение проблемы привязки к ОС хоста,
• удалённое хранение данных,
• бэкап или миграция данных на другой хост с Docker (для этого надо остановить все контейнеры и скопировать содержимое из каталога тома в нужное место).

Монтирование каталога с хоста (bind mount)

Это более простая концепция: файл или каталог с хоста просто монтируется в контейнер.

Используется, когда нужно пробросить в контейнер конфигурационные файлы с хоста. Например, именно так в контейнерах реализуется DNS: с хоста монтируется файл /etc/resolv.conf.

Другое очевидное применение — в разработке. Код находится на хосте (вашем ноутбуке), но исполняется в контейнере. Вы меняете код и сразу видите результат. Это возможно, так как процессы хоста и контейнера одновременно имеют доступ к одним и тем же данным.

Особенности bind mount:

1. Запись в примонтированный каталог могут вести программы как в контейнере, так и на хосте. Это значит, есть риск случайно затереть данные, не понимая, что с ними работает контейнер.
2. Лучше не использовать в продакшене. Для продакшена убедитесь, что код копируется в контейнер, а не монтируется с хоста.
3. Для успешного монтирования указывайте полный путь к файлу или каталогу на хосте.
4. Если приложение в контейнере запущено от root, а совместно используется каталог с ограниченными правами, то в какой-то момент может возникнуть проблема с правами на файлы и невозможность что-то удалить без использования sudo.

Когда использовать тома, а когда монтирование с хоста

Volume	Bind mount
Просто расшарить данные между контейнерами.	Пробросить конфигурацию с хоста в контейнер.
У хоста нет нужной структуры каталогов.	Расшарить исходники и/или уже собранные приложения.
Данные лучше хранить не локально (а в облаке, например).	Есть стабильная структура каталогов и файлов, которую нужно расшарить между контейнерами.

Монтирование tmpfs

Tmpfs — временное файловое хранилище. Это некая специально отведённая область в оперативной памяти компьютера. Из определения выходит, что tmpfs — не лучшее хранилище для важных данных. Так оно и есть: при остановке или перезапуске контейнера сохранённые в tmpfs данные будут навсегда потеряны.

На самом деле tmpfs нужно не для сохранения данных, а для безопасности, полученные в ходе работы приложения чувствительные данные безвозвратно исчезнут после завершения работы контейнера. Бонусом использования будет высокая скорость доступа к информации.

Например, приложение в контейнере тормозит из-за того, что в ходе работы активно идут операции чтения-записи, а диски на хосте не очень быстрые. Если вы не уверены, в какой каталог идёт эта нагрузка, можно применить к запущенному контейнеру команду docker diff . И вот этот каталог смонтировать как tmpfs, таким образом перенеся ввод-вывод с диска в оперативную память.

Такое хранилище может одновременно работать только с одним контейнером и доступно только в Linux.

Общие советы по использованию томов

Монтирование в непустые директории

Если вы монтируете пустой том в каталог контейнера, где уже есть файлы, то эти файлы не удалятся, а будут скопированы в том. Этим можно пользоваться, когда нужно скопировать данные из одного контейнера в другой.

Если вы монтируете непустой том или каталог с хоста в контейнер, где уже есть файлы, то эти файлы тоже не удалятся, а просто будут скрыты. Видно будет только то, что есть в томе или каталоге на хосте. Похоже на простое монтирование в Linux.

Монтирование служебных файлов

С хоста можно монтировать любые файлы, в том числе служебные. Например, сокет docker. В результате получится docker-in-docker: один контейнер запустится внутри другого. UPD: (*это не совсем так. mwizard в комментариях пояснил, что в таком случае родительский docker запустит sibling-контейнер). Выглядит как бред, но в некоторых случаях бывает оправдано. Например, при настройке CI/CD.

Монтирование /var/lib/docker

Разработчики Docker говорят, что не стоит монтировать с хоста каталог /var/lib/docker, так как могут возникнуть проблемы. Однако есть некоторые программы, для запуска которых это необходимо.

Ключ командной строки для Docker при работе с томами.

Для volume или bind mount:

Команды для управления томами в интерфейсе CLI Docker:

Создадим тестовый том:

Вот он появился в списке:

Команда inspect выдаст примерно такой список информации в json:

Попробуем использовать созданный том, запустим с ним контейнер:

После самоуничтожения контейнера запустим другой и подключим к нему тот же том. Проверяем, что в нашем файле:

То же самое, отлично.

Теперь примонтируем каталог с хоста:

Docker не любит относительные пути, лучше указывайте абсолютные!

Теперь попробуем совместить оба типа томов сразу:

Отлично! А если нам нужно передать ровно те же тома другому контейнеру?

Вы можете заметить некий лаг в обновлении данных между контейнерами, это зависит от используемого Docker драйвера файловой системы.

Создавать том заранее необязательно, всё сработает в момент запуска docker run:

Посмотрим теперь на список томов:

Ещё немного усложним команду запуска, создадим анонимный том:

Такой том самоуничтожится после выхода из контейнера, так как мы указали ключ –rm.

Если этого не сделать, давайте проверим что будет:

Хозяйке на заметку: тома (как образы и контейнеры) ограничены значением настройки dm.basesize, которая устанавливается на уровне настроек демона Docker. Как правило, что-то около 10Gb. Это значение можно изменить вручную, но потребуется перезапуск демона Docker.

При запуске демона с ключом это выглядит так:

Однажды увеличив значение, его уже нельзя просто так уменьшить. При запуске Docker выдаст ошибку.

Если вам нужно вручную очистить содержимое всех томов, придётся удалять каталог, предварительно остановив демон:

Если вам интересно узнать подробнее о работе с данными в Docker и других возможностях технологии, приглашаем на двухдневный онлайн-интенсив в феврале. Будет много практики.

Автор статьи: Александр Швалов, практикующий инженер Southbridge, Certified Kubernetes Administrator, автор и разработчик курсов Слёрм.