I have a container that has several volumes mapped to local folders. The volumes mount correctly and I can explore the local files through a bash into the container. All of these volumes can write to the local folders and I’ve successfully viewed logs and other files that the container created in the local folders. However, the container refuses to use the local files for any function within the container. All functions that search for these files return file-not-found errors, but have no problem writing logs and other output at the same time.
The overall effect is as if there is only one- communication direction … from the container to the local folders, but not the other way around. The local volumes are shared via Docker Desktop. It seems like this would be some kind of permissions issue, but I can’t determine what permissions would cause write-only to the local volume. There doesn’t appear to be any permissions issues within the container and with Docker Desktop allowing the Windows side, where would I go next to resolve the issue?
Did you look at the files with ls -l? If you mount from the Windows file system it may happen that all files and folders are drwxrwxrwx and the code you use can’t distinguish between them.
Thanks for the reply. Looking in the running container does indeed show that all linked/volumized folders have the permissions structure you referenced, while the folders that aren’t volumized do not. I’m afraid I don’t grasp the significance of this (I’m generally not a linux user). I have other containers running in the same environment that have no issues with reading and writing. Do you happen to know if any specific permissions can be set (on windows or in the container) to allow two-way communication? I’ll see if I can open up those other containers and check out the permissions set on them as they’re very similar in function, although running a different software program.
As I tried to explain, it’s not about two-way communication but about file permissions. If other containers are running fine this probably means that the software you run in this one isn’t able to work with the mounted files. In general you get a lot of improvements if you upgrade to Windows 2004 and use Desktop with WSL2. Just take care, your data will not be moved magically into the new environment. I had some similar issues, for example applications not restarting when files are changed, that were all solved with WSL2 and the new approach that is used here to mount files and folders.
Thanks again. I know the software can use the files as it can read and use them all directly if I copy the files into the image during image creation, just not when using volumes. I’m currently using Windows 10. I have WSL2, but haven’t attempted to run the container in it. I have run the program under WSL2 outside of Docker just to ensure it was working correctly, which it was. I’ll see about getting this to run with Docker under WSL2. Again, thanks for your time.