Trouble mounting Windows network drive to docker container

[jacksonjacobs1]

I mounted a windows network drive (G:) to the histoqc docker container using -v /g:/data.

The drive is accessible within the docker container in /data, but only a small subset of the file system is accessible.

This problem does not occur when mounting a regular (non-network) drive to the docker container. The problem also does not occur when the host machine is running linux.

Although this problem has nothing to do with HistoQC, we need to think about updating the documentation with recommendations for feeding data from different sources into HistoQC.

i.e, HistoQC should be compatible with S3, NAS and local storage. If Windows-mounted remote file systems cannot easily be mounted to the docker container, we should recommend that the user mount the network drives directly into the docker container.

[choosehappy]

i saw this:

-v /g:/data

and kind of vomited in my mouth a bit.... i guess technically it should be possible, and I'm not 100% sure why it wouldn't work - but the chaining of technologies that would need to be in place for that to work are pretty impressive...

you know, I do wonder if the issue is that as a result of the mounting within docker the metadata of the mount type gets lost? if I remember correctly, there are special flags that are normally set for remote shares which make them more robust - like, longer latencies when waiting for responses?

[jacksonjacobs1]

Haven't confirmed yet, but I think the correct way to do this is to create a named docker volume:

https://docs.docker.com/storage/volumes/#create-cifssamba-volumes

docker volume create \
    --driver local \
    --opt type=cifs \
    --opt device=//uxxxxx.your-server.de/backup \
    --opt o=addr=uxxxxx.your-server.de,username=uxxxxxxx,password=*****,file_mode=0777,dir_mode=0777 \
    --name cif-volume

And then mount the cifs volume to the container.

[choosehappy]

yyeaaaaaaaa this makes a lot of sense and is inline with my previous comment:

Under the hood, the --mount flag using the local storage driver invokes the Linux mount syscall and forwards the options you pass to it unaltered. Docker doesn't implement any additional functionality on top of the native mount features supported by the Linux kernel.

this would probably be catastrophic in the case of e.g., remote storage. aligning with the correct volume driver is going to make things..you know..work : )

[jacksonjacobs1]

Interesting... But meanwhile, there are no issues with mounting a regular windows drive to the container.

Wouldn't we expect problems when mounting e.g. an NTFS-formatted drive to the container's linux-compatible file system?

[choosehappy]

i have no evidence, but my intuition is that the kernel level drives can successfully interact with the NTFS in a way/speed that doesn't create any issues. there is a much bigger difference in doing remote storage access due to latency, read/write permissions. keep in mind NTFS is a file system, mounting a network share is done via e.g., CIFS which is a network protocol. they have different needs/requirements and thus likely don't have the same total overlap in functionality