Share and learn in the Docker community.
I updated my Docker Desktop to version 2.2.0.0 today. When I started up my container (web server), it could no longer find files within the container (for example, /var/www/index.html is not found). When I log into the container and browse the files, the files are definitely there. I tried chmod -R 777 / just to see if it was a permission issue, but that didn’t fix anything.
What changed in this version of docker? What can I do to fix this?
I also updated to version 2.2.0.0 today. It’s been driving me crazy all morning. The docker container from the command line shows all my files are still there, but the web application server is unable to find them now.
I’ve been troubleshooting all morning, I even tried removing docker desktop, reinstalling and building the images and containers again but that didn’t work. I would love to know how to get past this as well.
I was able to get it to work after removing docker desktop and reinstalling a saved exe for version 2.1.0.5 in my downloads, I was able to rebuild everything and get the environment running again.
I also updated to version 2.2.0.0 today and after that the folder sharing between local (Windows) host and container does not work anymore. The command
docker run --rm -v C:\dev\Tests:/tests -it test/testcafe -e chromium:headless /tests/Login.js
was working fine on my previous docker version, but since the update it returns an error:
docker: Error response from daemon: error while creating mount source path '/host_mnt/c/dev/Tests': mkdir /host_mnt/c/dev: file exists.
This is regardless of enabling drive sharing globally in the settings, or on demand via cmd windows.
Furthermore, sharing on demand does only work in Windows cmd, but not in Powershell, where the command fails with the error above straight away without sharing popup being displayed.
it looks like docker starts caching for basic volumes by default for me helps change
volumes:
- .:/home/wwwroot/sf4
to
volumes:
- type: bind
source: .
target: /home/wwwroot/sf4
consistency: consistentI also installed Docker 2.2 yesterday and immediately ran into the same problems:
ERROR: for app Cannot start service app: error while creating mount source path ‘/host_mnt/c/projects/myproject…’: mkdir /host_mnt/c/projects: file exists
ERROR: Encountered errors while bringing up the project.
I tried sharing the C drive - restart, reboot, etc, no luck. Uninstalled and reinstalled and got the same issue. Uninstalled and deleted the docker files in ProgramData. No luck. Wait, why were those files still there after an uninstall? That’s stupid.
Went back to version 2.1. It works!
Some testing by actual humans would be nice.
Also having this problem after updating to 2.2.0 forcing me to downgrade to 2.1.0.5
I have a volume in the docker compose with this mapping:
volumes: ../path/to/dir:/app/path/to/dir
After running docker-compose with
ENTRYPOINT ls -la path/to/dir && npm run start
I can see that the file does exist at this point. However, the file does not exist when doing an ls -la from inside the nodejs instance running on the container.
downgrading to 2.1.0.5 fixed this issue.
Wasted a few hours trying to figure out the issue until I just gave up and downgraded
Possibly important edit:
/path/to/dir is actually a parent directory that contains multiple folders with a semantic version naming scheme.
eg:
/path/to/dir/9.0.15/file.js, /path/to/dir/9.0.14/file.js etc. Those do get found however the one that fails is /path/to/dir/latest/file.js
Also having this problem. Downgrading
I was hoping wouldn’t have to downgrade
I’m running into all sorts of issues getting dev containers to work in VSCode after upgrading (search only works on open files, VSCode thinks open files are dirty and frequently prompts user for additional actions on save, etc.).
One of the issues with volumes, however, seem to be due to case sensitivity. If your volume path did/does not respect case, that might be the source of some of the errors here. Pre 2.2 update, case sensitivity didn’t seem to matter, now it does.
Assuming your folders are the same case (e.g. C:\dev\Tests exists on your windows pc), try:
docker run --rm -v //c/dev/Tests:/tests -it test/testcafe -e chromium:headless /tests/Login.js
Same problems here. Also the switch to consistent mounts does not help. Does anyone have a solution other than downgrading yet?
Same problem hiere!
Reinstalling docker, redownloading repo, updating windows drivers, updating windows itself.
I dont know what done the trick but you guyz should try!
(I would bet on updating windows)
I have the same problem!
It seems to that I encountered same problem after upgrading to Docker Desktop Windows 2.2.0.3. I tried to enable C:\ and D:\ on windows as https://docs.docker.com/docker-for-windows/
but it still was failed.
PS C:\Users\User> docker run --rm -it -p 27470:27470 -v c:/.:/data_c -v d:/.:/data_d ubuntu_richard /bin/bash
C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: file does not exist.
See ‘C:\Program Files\Docker\Docker\resources\bin\docker.exe run --help’.
Does anyone have another solution except downgrade docker?
This could be related to issue 5567 that was solved in edge version 2.2.1.0. You could try this one, if you don’t forget that it is experimental code.
My 2 cents here, before the upgrade the cmd included: -v C:\Real\Path:/docker/path/
After the upgrade, got the “Error response from daemon: file does not exist” error
The error was resolved after updating the cmd to include: -v C:\Real\Path:/docker/path/
I’ve just installed Docker Desktop for Windows 2.3.0.3 (after having skipped updating to 2.2.0.0) and I’m getting the same issue. Every time I try to start my containers I get the error Error response from daemon: error while creating mount source path: mkdir /host_mnt/c/: file exists docker windows. They all worked prior to the update to 2.3.0.3.
Is there any plan to fix? For now I’ll be downgrading to 2.1.0.5 as previously suggested.
Steps to reproduce the behavior
start a container with shared folder
edit in windows a file in the shared folder
the file is not changed in the container