[WSL2] Fail to mount file/directory on windows startup (trying to start container too early ?) #13947
Comments
|
Updated to |
|
I found an issue committed in 2017 with the same problem #584 . Someone official explained that host-mount volumes are not available in a few seconds after docker starts. It is tracked bu not fixed yet, so I think they will never fix it. An alternative solution is to give up docker's autostart funtion, and use windows task scheduler instead. Create a task to start your containers with WSL console after logging on, remember to set a delay to ensure docker is started completely before the task triggered. Here is a command for starting all containers: |
|
@CharlesChou73 Well, I came up with a similar solution some weeks ago... #!/bin/bash
while true; do
if [ "$(docker info -f "{{.OSType}}" 2> /dev/null)" ]; then
echo "Docker running"
break
fi
sleep 1
done
echo "Restarting"
for service in $(docker compose ls --format=json | jq -rc ".[] .ConfigFiles"); do
docker compose --file "$service" restart &
doneA while true loop wait for docker to be running and available inside WSL and then restart all docker compose stacks. I found that having the It's hacky as fuck, but working for me ^^ |
|
@Tristan-MyAnaPro That's instructive! I think your solution is more elegant ヾ(≧▽≦*)o |
|
FYI, i just downgrade docker desktop to 4.24.2, and the bug gone, refer to #13985 |
Downgraded to 4.24.2, and it works well, thanks a lot! |
|
I have same issue in 4.30.0 :S 4.24.2 is dated of 12-10-2023... need fix please... |
|
Cross post from #13985 (comment) 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 |
|
@longzheng This is good informations 👍. However, your findings and workaround only apply for files mounted from the Windows filesystem, the problem I encounter is for files mounted from the WSL filesystem (and impact files and directory mount). @bsousaa After upgrading to 4.31.0 the problem is still present, can you update the tags ? |
|
Just updated to 4.32.0, problem is still present
|
Do you have some explanation for it . |
The theory is that Docker is trying to start and use the WSL mount before WSL is loaded/ready. |
@longzheng |
|
@longzheng hi i have a query here, I if use task scheduler and put a delay in docker desktop starting while we restart the system, can we avoid this issue |
I am not sure, I have not tested this scenario but I would guess it might work. |
|
same problem ! |
|
Solved by doing this:
This will run once when you start a new terminal session in a Docker bind mount directory. I shared it in SO, too, don't forget to upvote if it was useful so more people find it if they need: https://stackoverflow.com/a/78778206/3198983 |
|
@gsusI Either I'm missing something or... this has nothing to do with the issue I encounter no ? @bsousaa I did not ping you for every version but as you may guess, this problem is still present and seen on The only solution I found is to run a script on WSL startup to force a restart of every docker compose stack when the docker engine is available (see : #13947 (comment)) |
|
The solution for me was to run docker-compose.exe from the Windows Powershell after changing to the directory via cd \wsl$\Ubuntu\home\user\yourdockercomposerfiledir\ - I tried the script inside of my WSL Ubuntu instance referenced above and it didn't seem to automatically restart my docker images after reboot like running docker-compose.exe did. But on second review it appears to have lost my local files and configuration when starting that way but restarting it directly from the Ubuntu WSL terminal restores them. So I think this bug is still there. My goal is to simply just have a few services running that restart automatically when I reboot my computer w/o needing to run an additional task or open up any command prompt. Edit: So the only solution I was able to get working was for those docker containers I wanted to run automatically when I log into windows I had to move the docker-compose.yml file and the mounted folders out of my WSL environment and onto a windows directory and when starting them via running |
Description
Hi,
I encounter an error each time docker start on logon where it fail to mount bind-mounts volumes.
Stopping the containers and restarting them fix the problem, so this is not a problem from the files themselves.
The stack is as follow:
wsl --version:restart: unless-stoppedso they start when docker startIt happen to me and my colleague BUT it wasn't happening to him with is older computer which was way less powerful... It seems like to reproduce you need a powerful computer, as if docker was starting "too fast" and the mount in
/mnt/wslis not totally ready.My computer is the MSI Stealth 15M B12UE-042 for spec references.
I don't really know which log to look at to debug, I'm creating this issue with the hope to have maintainers / community help me reduce the scope until we can find a consistent way to reproduce.
Reproduce
This steps give me a 100% reproduction rate on my computer !
Have docker configured to start on windows logon.
In WSL2, execute:
docker compose up -d"Error": "failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting \"/run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/19f14e3a7e077143cb6a2752001de60bd840e54322e03be340183c88e743959a\" to rootfs at \"/var/www/test-file\": mount /run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/19f14e3a7e077143cb6a2752001de60bd840e54322e03be340183c88e743959a:/var/www/test-file (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type",If I check the aforementioned file on the filesystem, it's correctly here with the right content:
Expected behavior
The container start and the bind-mounts are properly mounted.
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
687632F8-FD33-48ED-8E81-B7A273C2A133/20240303145659
Additional Info
I tested and reproduced the problem even with only one stack starting, itself containing only one container
The text was updated successfully, but these errors were encountered: