Volumes not initially mounting for services that restart on windows reboot #13985
Comments
|
@SpikyClip / @bsousaa Possibly a duplicate of the issue I encounter too ? #13947 |
|
I'm experiencing the same issue. I have mariadb instance which mounts a local folder to /var/lib/mysql ... when I boot the computer, it does not mount the folder correctly although docker inspect shows it as mounted. But when you docker-compose exec into the container, I can see the default directory structure for freshly launched mariadb instance. |
|
I'm having the same problem with docker-desktop 4.28.0, the volume mount fails on a windows reboot, but it works fine on a manual startup. When I roll back the version of docker-desktop to 4.20.0, I don't have this problem. |
|
I tried downgrading to |
|
I have same issue in 4.30.0 :S 4.24.2 is dated of 12-10-2023... need fix please... |
|
Same issue for me, i downgraded for now but hope its fixed in next version |
|
I'm running into this bug on Windows as well with the Powerwall-Dashboard container (although it doesn't seem to affect my other Teslamate container).
I can also verify that I tested different versions all the way up to |
|
I can confirm that version |
|
Looking at dockur/dnsmasq#4, I also checked my I concur that this smells like a race condition with WSL2 when using bind mounts. |
|
Just want to call out that a side effect to the bind mounts being created too early, seems to resulting in docker not seeing that the folder structures already exists, which if you're using the docker compose shorthand syntax instead of Docker will always create the path prior to the container as root, which causes all kinds of havoc to your permissions if you're trying to run as the usual UID:GID, 1000:1000. |
|
After hours of trial and error testing, I have narrowed down this problem specifically to just bind mounting files (not folders) and using WSL2 for docker-compose. ReproductionThe simplest repro I came up with was basically a services:
influxdb:
image: influxdb:1.8
restart: always
ports:
- "8086:8086"
volumes:
- "./influxdb.conf:/influxdb.conf"
# alternatively can use the type: bind syntax which has the same issue
# - type: bind
# source: ./influxdb.conf
# target: /influxdb.confThen just create a blank called The most important step to reproduce this issue is to initialize the docker container using WSL. So first type This will create the container with a bind mount of
Then if you log out or restart and log back in, the container will have a status of
WorkaroundI found as a workaround, if you start the docker compose from Windows (command prompt), not WSL2, then it will work correctly. For example from the same directory just run
This container will start correctly if you log out and log back in. LogsWhen it fails with WSL bind mount When it works with Windows bind mount |
Tried 4.26.0 seems to be working fine. So between 4.26 - 4.28 (just wanted to try first 2024 release at least for the time being) |
|
Running 4.35.1, still the same issue |
Description
I am having the exact same issue as #584 on Docker Desktop 4.28.0 (139021) for Windows.
Essentially on computer boot, when the service restarts, the containers cannot find the volumes so it appears like its the first setup. But when the services are restarted manually, the volumes are mounted with no issues.
This make startup services useless as they can't access the volumes they need. I suspect it has something to do with delayed WSL2 startup, or the mount paths I used in the compose file.
docker-compose_truncated.yml.txt
Reproduce
sudo docker-compose up -dExpected behavior
Volumes should be mounted correctly when docker desktop starts on windows reboot.
docker version
Client: Cloud integration: v1.0.35+desktop.11 Version: 25.0.3 API version: 1.44 Go version: go1.21.6 Git commit: 4debf41 Built: Tue Feb 6 21:13:00 2024 OS/Arch: linux/amd64 Context: default Server: Docker Desktop Engine: Version: 25.0.3 API version: 1.44 (minimum version 1.24) Go version: go1.21.6 Git commit: f417435 Built: Tue Feb 6 21:14:25 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Diagnostics ID
E82A5D0F-B3D8-4BED-9935-9D986C6BB0D8/20240322090128
Additional Info
No response
The text was updated successfully, but these errors were encountered: