Volumes from docker-compose file no longer working after a reboot

[alexharrington]

When launching a set of containers with docker-compose on Docker for Windows, initially, everything works as expected. Data persisted to the local machine's drives via volume mounts is written back to the host machine.

Stopping and starting the containers also works as expected - the persisted data is correctly mounted inside the container.

When rebooting the host machine, the restart policy of the containers ensures they automatically start, however the persistent data is no longer visible from inside the container, and so it appears as if it's the first time the containers have been run.

mount command run inside the MySQL container after a restart. Notice there's no mount for /var/lib/mysql

PS C:\xibo-docker> docker exec -ti xibodocker_cms-db_1 bash
root@a135ac0c4c74:/# mount
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/W6VSNU5UMWPTCMHY6HBFU72DGS:/var/lib/docker/ov
erlay2/l/T4IM4NAW5ZLELTCTIGQVZEV5TM:/var/lib/docker/overlay2/l/BVWS7GCUFBACXDBE5GTTUEF75Y:/var/lib/docker/overlay2/l/GH3
7OFGKSF6RAKQM6YDJMQMCTJ:/var/lib/docker/overlay2/l/VOEFLKUBI2TCNXBR2SRN6P6AQF:/var/lib/docker/overlay2/l/NL6X6D4A4GNDAMO
XJF2H4JLLAQ:/var/lib/docker/overlay2/l/TD2PWJPYRWTEZ7D6U75AEWSY2B:/var/lib/docker/overlay2/l/6GSQWPDGDHTXUFM6PEWKZ6KUYE:
/var/lib/docker/overlay2/l/XN7PPINODHWFDHHP3G3FBPWCWR:/var/lib/docker/overlay2/l/UJ4FTANFQ4KIMVPE3GAYXMJLT3:/var/lib/doc
ker/overlay2/l/24BGPIQYW25Q5RORK7FTF3EUD7:/var/lib/docker/overlay2/l/IB5GJWDXNIG2JJKTAMLVBUMDSR,upperdir=/var/lib/docker
/overlay2/a7cfee069ea0ff7582c6590447740057de395d76ca85bebabebce81f7471d748/diff,workdir=/var/lib/docker/overlay2/a7cfee0
69ea0ff7582c6590447740057de395d76ca85bebabebce81f7471d748/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
openrc on /sys/fs/cgroup/openrc type cgroup (ro,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-age
nt.sh,name=openrc)
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
blkio on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
memory on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
freezer on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
net_cls on /sys/fs/cgroup/net_cls type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls)
perf_event on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
net_prio on /sys/fs/cgroup/net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_prio)
hugetlb on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
pids on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,name=systemd)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /etc/resolv.conf type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /etc/hostname type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /etc/hosts type ext4 (rw,relatime,data=ordered)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
tmpfs on /var/lib/mysql type tmpfs (rw,relatime)
proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
root@a135ac0c4c74:/#

Simply stopping and starting the containers rectifies the issue:

PS C:\xibo-docker> docker-compose stop
Stopping xibodocker_cms-web_1 ... done
Stopping xibodocker_cms-xmr_1 ... done
Stopping xibodocker_cms-db_1 ... done
PS C:\xibo-docker> docker-compose start
Starting cms-db ... done
Starting cms-xmr ... done
Starting cms-web ... done
PS C:\xibo-docker> docker exec -ti xibodocker_cms-db_1 bash
root@a135ac0c4c74:/# mount
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/W6VSNU5UMWPTCMHY6HBFU72DGS:/var/lib/docker/ov
erlay2/l/T4IM4NAW5ZLELTCTIGQVZEV5TM:/var/lib/docker/overlay2/l/BVWS7GCUFBACXDBE5GTTUEF75Y:/var/lib/docker/overlay2/l/GH3
7OFGKSF6RAKQM6YDJMQMCTJ:/var/lib/docker/overlay2/l/VOEFLKUBI2TCNXBR2SRN6P6AQF:/var/lib/docker/overlay2/l/NL6X6D4A4GNDAMO
XJF2H4JLLAQ:/var/lib/docker/overlay2/l/TD2PWJPYRWTEZ7D6U75AEWSY2B:/var/lib/docker/overlay2/l/6GSQWPDGDHTXUFM6PEWKZ6KUYE:
/var/lib/docker/overlay2/l/XN7PPINODHWFDHHP3G3FBPWCWR:/var/lib/docker/overlay2/l/UJ4FTANFQ4KIMVPE3GAYXMJLT3:/var/lib/doc
ker/overlay2/l/24BGPIQYW25Q5RORK7FTF3EUD7:/var/lib/docker/overlay2/l/IB5GJWDXNIG2JJKTAMLVBUMDSR,upperdir=/var/lib/docker
/overlay2/a7cfee069ea0ff7582c6590447740057de395d76ca85bebabebce81f7471d748/diff,workdir=/var/lib/docker/overlay2/a7cfee0
69ea0ff7582c6590447740057de395d76ca85bebabebce81f7471d748/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
openrc on /sys/fs/cgroup/openrc type cgroup (ro,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-age
nt.sh,name=openrc)
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
blkio on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
memory on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
freezer on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
net_cls on /sys/fs/cgroup/net_cls type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls)
perf_event on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
net_prio on /sys/fs/cgroup/net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_prio)
hugetlb on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
pids on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,name=systemd)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /etc/resolv.conf type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /etc/hostname type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /etc/hosts type ext4 (rw,relatime,data=ordered)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
//10.0.75.1/C on /var/lib/mysql type cifs (rw,relatime,vers=3.02,sec=ntlmssp,cache=strict,username=alex,domain=ALEX-Z930
,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.75.1,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,mapposix,
nobrl,mfsymlinks,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
root@a135ac0c4c74:/#

Information

• Diagnostic ID from "Diagnose & Feedback" in the menu.
  70292EF9-2E63-4FF6-88A3-8C42E7C4A28F/2017-03-14_15-52-24

• host distribution and version (Windows version, build number, etc)
  Windows 10 Pro 64 bit 1607

PS C:\xibo-docker> docker --version
Docker version 17.03.0-ce, build 60ccb22
PS C:\xibo-docker> docker-compose --version
docker-compose version 1.11.2, build f963d76f
PS C:\xibo-docker>

Steps to reproduce the behavior

1. docker-compose files available here: https://github.com/xibosignage/xibo-cms/releases/tag/1.8.0-rc3
2. Extract to eg c:\xibo-docker
3. Ensure C is shared in Docker for Windows
4. Change docker-compose.yml file version to 2.1 as I believe there are issues on Windows with 2.0
5. Copy config.env.template to config.env and set a random MySQL password in config.env
6. docker-compose up -d
7. Open a browser to http://localhost
8. Login - Username: xibo_admin, Password: password
9. Change password (click on the avatar icon top right)
10. Log out/in to verify password change
11. Reboot host machine
12. Once rebooted, attempt to login and password will have reverted to "password" rather than what you selected
13. docker-compose stop then docker-compose start and you can then log in again with your changed password.

[friism]

The host-mount volume is not available immediately upon Docker start but becomes available a few seconds later. For that reason, containers autostarted with -d that rely on host mounts won't work. We have an internal issue tracking this.

[Bothari]

I'm hitting this issue as well. As a developer completely new to Docker, can anyone recommend a workaround until the issue is resolved? Would I be better off just changing the restart policy to "no", and writing a script to manually start them up?

[default-writer]

@Bothari

Try Power Shell 3 command under Adminstator access rights as follows:

Set-NetConnectionProfile -interfacealias "vEthernet (DockerNAT)" -NetworkCategory Private

Then enable drive C,D share in Docker settings.

[tdroenner]

This problem also applies to docker running on Linux.

[oldeb]

Same issue on Ubuntu after computer restart

oldeb@bowser:~$docker inspect 3c04b16ae034
...
"Mounts": [
            {
                "Type": "bind",
                "Source": "/home/oldeb/projects/thing/code/src",
                "Destination": "/var/www/html",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
...

root@3c04b16ae034:/var/www/html# ls -la
total 8
drwxr-xr-x 2 root root 4096 Sep 21 07:40 .
drwxr-xr-x 1 root root 4096 Jun  9 03:04 ..`

oldeb@bowser:~/projects/thing/code/src$ ls -la
total 20
drwxrwxrwx  9    82    82   4096 oct 24 11:56 .
drwxrwxr-x  5 oldeb oldeb   4096 nov  6 11:46 ..
-rw-rw-r--  1 oldeb oldeb    549 oct 24 11:56 index.php

Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

Client:
Version: 17.09.0-ce
API version: 1.32
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:42:18 2017
OS/Arch: linux/amd64

Server:
Version: 17.09.0-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:40:56 2017
OS/Arch: linux/amd64
Experimental: false

[josejayesh]

I am facing the similar issue with windows shared volumes . If I am using the same compose file with Mac Os host/ Linux host not seeing any issue with shared volumes . @friism can you confirm this is windows host specific issue ?

My compose file looks as follows

[Xtrazyx]

Any workaround ?

[tdroenner]

Sure. docker restart <container>. I've placed this in cron which is executed after reboot. 2018-01-24 12:58 GMT+01:00 Xtrazyx <[email protected]>:

…

Any workaround ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGNlyMeTTnbrfSthLmHeyx_197PgQ_PVks5tNxrUgaJpZM4Mcy5X> .

[Xtrazyx]

Ok since i am on Windows 10 (!!!) i have had to make the ScheduleJob Powershell Script counterpart :)

[EcoFreak]

Would a named volume fix this issue or will the docker-compose start -d face the same problem?
I'm having this problem in Windows.

[Xtrazyx]

The problem is caused at system start up only, so docker-compose start -d should work.

[MikhailTymchukDX]

Will moving to swarm with single worker node resolve the problem?
When manager assigns a task to a worker, is it warmed up to bind volumes correctly?

[zeeshan2523806]

@friism that does not work all the time even restarting the container manually can mount the data but with an old version not the latest version...

[shayne]

Any update on this or official recognition from Docker on this? Real shame that host_mnt volumes with auto-start just don't work.

Are there any graceful workarounds?

[Terror-Gene]

Thank god i found this page! I'm new to docker & started testing it out over several days but had containers getting reset & couldn't work out why. So after a while, out of frustration, I gave up & uninstalled docker. I wanted to use it though, so a few months later (now) I tried it again & this time figured out the volume is missing only if the container auto starts. which brought me here. How many other people have this issue & can't work it out & end up leaving docker for an alternate solution?

Is there any easy workaround?
Anyone using task scheduler, how do you make sure docker is running before trying to start a container?

This seems like a major issue & I'm surprised it wasn't resolved the day after it became known. I assume by delaying container launches until the mount is ready.

[shayne]

I wrote a container shaynesweeney/holdup that is a simple Go app that uses the Docker API to start stopped containers once the volume /test shows a file (i.e. the mount is good). So add the volume /test and map it to a host mount with at least one file inside of it, also pass in /var/run/docker.sock as :ro to the container.

Create the holdup container with --restart=always and do not add a --restart= for any other containers.

docker run --name holdup
              --restart always
              -v /host_mnt/c/some/path/to/holdup:/test
              -v /var/run/docker.sock:/var/run/docker.sock:ro
              shaynesweeney/holdup

Here's the source:
https://gist.github.com/shayne/c7f4314e280f926b9b61d5ad3a4c6a83

This is working well. Also has the side effect of starting containers if they were stopped.

EDITED: changed to reflect c1n1c0's findings

[Terror-Gene]

Thanks for your suggestion, but with my lack of docker knowledge I'm stuck with a
"panic: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" error.
I've tried to read up what to do, but it seems I'm getting lost down this rabbit hole...
Is there something simple I'm overlooking?

[shayne]

did you pass in /var/run/docker.sock to the holdup container?

[Terror-Gene]

wasn't aware i had to do that. seems to be working now.
to clarify, i ran:
docker run -d --name=holdup --restart=always -v c:\docker\holdup:/test -v /var/run/docker.sock:/var/run/docker.sock shaynesweeney/holdup
does that sound correct? & thank you for your help!

[shayne]

Yeah just make sure there's a file in C:\docker\holdup and it should bring any stopped containers up once the host mount is ready.

[Terror-Gene]

done & done. legend. thank you! hopefully this issue can be resolved in the near future.

[zhangalex]

It's likely still not fixed on windows. However, Linux and Mac working very well.

[Y2zz]

This problem can actually exist for two years, it really makes me stunned.

[Y2zz]

Has anyone been able to solve this problem? @mikeparker

[mikeparker]

Thanks for your patience on this one.
We're looking into this, hopefully I can provide an update soon.

It would also be great to get more in-depth use cases for this: what kinds of data/containers are you running and is this for development or production usage?

[collinsauve]

It would also be great to get more in-depth use cases for this: what kinds of data/containers are you running and is this for development or production usage?

My use case:

• Docker for Windows
• Ubuntu VM in Hyper-V
• Development only
• Containers include:
  • Cassandra
  • Redis
  • MS SQL-Server
  • ElasticSearch

While all of the above containers needed mounted data and config volumes from the Windows host, I've only ever experienced Cassandra being affected by this bug.

[Y2zz]

I am using docker for win in the development environment.
using a Linux container and the latest version.

This is my docker-compose.yml

[tanushshukla]

@mikeparker commented on 15 Jan 2019, 15:28 GMT:

Thanks for your patience on this one.

We're looking into this, hopefully I can provide an update soon.

It would also be great to get more in-depth use cases for this: what kinds of data/containers are you running and is this for development or production usage?
Yup, same for me as well. Docker for windows using linux containers.

[helnokaly]

Same for Linux, development use case.

I use docker/docker-compose inside a Vagrant VM (Virtualbox).

Host -> Vagrant VM -> Docker

Issue is with bind mounts volumes that is shared from host machine to VM, maybe it is not ready when docker containers starts. When I access the containers, the volume directory is there but empty. So I have to restart containers to fix it.

[michaelosthege]

For me the use case is a MySQL server on a Windows machine (production).

[skvalex]

The same problem on Ubuntu 18.04.1 LTS.

Auto-mount via /etc/fstab:
/dev/md125 /media/raid1 ext4 defaults,nofail 1 2

• Docker version 18.09.1, build 4c52b90
• docker-compose version 1.23.2, build 1110ad0

[Y2zz]

I upgraded the docker desktop today, but the problem still exists.

Version 2.0.0.3 (31259)
Channel: stable
Build: 8858db3

[c1n1c0]

I had the same problem in win10, using mysql and elabftw containers.
I could solve it with minor adaptations from @shayne solution.

[apodelko]

A side issue I spent some time on - disks stopped to map at all. It turned out that I changed Windows password - so it stopped mapping Windows drives without any special complains. After resetting credentials in Docker options got it working again.

That is on the top of the issue described in the thread - but, considering time I waste on that, decided to mention it here.

[evolart]

Same issue. I will be looking into some of the workarounds above later today.

Use case:

Running a MySQL container in Docker Desktop for Windows with /var/lib/mysql mounted to a volume that resides on a secondary HDD in my desktop. Container starts but with /var/lib/mysql empty and needs to be restarted before /var/lib/mysql mounts correctly with my databases.

[evolart]

I read the other workarounds and I was too lazy to figure out how to run Sean's Go script on Windows. This is what I threw together and it works. There is probably a better easier way to do this but it's good enough for my purposes.

I have my MySQL docker-compose.yml in D:\Docker\MySQL.

Do {
    $dockerps = (docker ps)
    Start-Sleep -S 5
} While (! $dockerps -contains "mysql")
Set-Location D:\Docker\MySQL
docker-compose restart

Added a Task Scheduler Task with the action Start a program to run the script.

Program/script: powershell.exe
Add arguments: -windowstyle hidden -file D:\Docker\MySQL-Restart.ps1

[zigi05]

I still have this issue. After Docker Desktop restart WordPress starts up in the original state and all previously added themes and plugins are lost.

[Formator]

Hi

After many hours I have somehow fix this issue on my system.

My Evirement:

• Windows Server 2016 Standard, Version 1607 OS Build: 14393.2969
• Docker with linux containers: master-dockerproject-2018-01-09, build 4c7749e5
  Version 18.01.0-ce-rc1-dev (15072)
  Channel: lcow; 0fc5e58
  Compose: 1.18.0
  Credential Helpers: 0.6.0
  Machine: 0.13.0
  Notary: 0.4.3
• I'm using docker stack deploy

Here are two things that I beleave has fix my problem:

1. Named volumes:

I have found this issue when I have in my docker-compose.yml file unamed volumes in services section, for example:

version: '3.4'

services:
  srv1:
    image: niceimage:latest
    network_mode: bridge
    volumes:
      - type: bind
        source: /host_mnt/d/tralala/web/data
        target: /app/data
    stop_grace_period: 20s
    deploy:
      mode: replicated
      replicas: 2
      update_config:
        parallelism: 1
        delay: 30s
        failure_action: rollback
      restart_policy:
        condition: any
        max_attempts: 3

Changing unamed volumes to named I almost fix the problem (after reboot I get different arror), here is my yml now:

version: '3.4'

services:
  srv1:
    image: niceimage:latest
    network_mode: bridge
    volumes:
      - nicesrv1-volume:/app/logs
    stop_grace_period: 20s
    deploy:
      mode: replicated
      replicas: 2
      update_config:
        parallelism: 1
        delay: 30s
        failure_action: rollback
      restart_policy:
        condition: any
        max_attempts: 3

volumes:
  nicesrv1-volume:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: /host_mnt/d/tralala/web/data

2. Change startup type of "Docker for Windows Service" from Automatic to Automatic (Deleyed Start)

I hope that this will help to someone with similar issue.

[tingjhenjiang]

I can confirm that it's not like what friism said two years ago that "The host-mount volume is not available immediately upon Docker start but becomes available a few seconds later."
I wasted endless time observing when there would be host mount files appeared in containers, only to find out that, there would not be any host mount files appeared in containers until I choose to restart docker.

my env:
Docker Desktop community for Windows v2.0.0.3(31259) build 8858db3
fresh install of Windows 10 Pro build 18362.239
Avast Premier Firewall
MySQL container, mounting my drive on /var/lib/mysql .

The workaround shaynesweeney/holdup gave is nice.

Sometimes this problem has something to do with firewall or docker built-in shared drive settings (including the credentials parts). If the problem persists, I recommend you to check and restart docker, firewall, shared drive settings and resetting shared drive credentials settings.

[DUWENINK]

I have the same problem

[zigi05]

What I did is removed always: yes from docker-compose.yml and start containers manually. That way everything works fine.

[v-ladynev]

A side issue I spent some time on - disks stopped to map at all. It turned out that I changed Windows password - so it stopped mapping Windows drives without any special complains. After resetting credentials in Docker options got it working again.

That is on the top of the issue described in the thread - but, considering time I waste on that, decided to mention it here.

I had the same problem. Thank you for help. Docker should output an error in such situation.

[mikeparker]

It turned out that I changed Windows password - so it stopped mapping Windows drives without any special complains.
I had the same problem.

@v-ladynev This was fixed with the latest release, are you sure you're using latest? From the release notes: (https://docs.docker.com/docker-for-windows/release-notes/)

Docker Desktop now checks for stored credentials at startup before attempting to mount any shared drives. This prompts users to reenter the credentials if they are invalid.

If you are still getting a shared drive silently failing to mount on boot please let me know.

[v-ladynev]

@mikeparker I was using an old version. So it was my mistake. Thank you.

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked