Open pwrightkcl opened 1 year ago
I moved my data to an EXT4 filesystem on the same system, and this problem does not occur. I restarted Docker Desktop, and the containers ran as before, whether started from Desktop or command line.
It looks like the issue is to do with the mount point being on a filesystem in NTFS format. Perhaps DD sees an NTFS filesystem and assumes it is running in Windows, hence adding the '/host_mnt' prefix. In that case, there needs to be an extra test of the actual OS it is running in, not just the filesystem being mounted (or perhaps only the former). The use case of a system dual booting Linux and Windows, with a data drive formatted NTFS so both can share cannot be that uncommon.
Note that the NTFS drive is used for data only. I have an EXT4 SSD where Linux is installed, and Docker and DD are also installed there. I have a separate EXT4 HDD in use as my Docker registry, since it refused to work on my NTFS HDD when I set up my base Docker installation way back when.
Description
After adding a directory to File sharing, it can be used as a volume mount for a container at first, but after restarting Docker Desktop, the container fails to run. It gives a 'permission denied' error with '/host_mnt' prepended to the local path in the volume mount.
This is happening in Linux. I have seen other issues relating to '/host_mnt' in Windows and Mac, but they do not appear to apply here.
Reproduce
In this example,
/path/to/local/directory
exists and was mountable the first time the container was run.Expected behavior
Docker Desktop should run the container the same every time, rather working at first then failing after a restart.
docker version
docker info
Diagnostics ID
6bbcfa55-ce44-4f40-881a-94fd86efca19/20230602154524
Additional Info
The directory I am using is on a device formatted NTFS and shared between Linux and Windows on this machine, which may be relevant.