Wow, closer to target thanks to your help. Not that I understand why this works. After all, my computer knows what 10.0.75.1 is.
/ # mount -t cifs //DieterPC/C /C -o username=Dieter,password=mypassword,noperm
/ # ls
C Database Mac bin c dev etc home init lib linuxrc media port proc root run sbin sys tmp usr
var
/ # ls C
$Recycle.Bin Documents and Settings Program Files (x86) Recovery Windows inetpub
BOOTNXT Dokumente und Einstellungen ProgramData Rtools autoexec.bat pagefile.sys
BOOTSECT.BAK IO.SYS
Glad to hear thatâs working now⊠your turn to let us know what did you do to make it to work⊠One thing I noticed: youâre mounting the share using the computer name instead of the IP addressâŠ
Mounting the share using the computer name instead of the IP address: I read this from your comment: âAnd use the computername instead of domain name in the cifs mount commandâ. The blame goes to you
However, I do not think that this is a solution, just a way of getting it to work in my setting. After all, this should work without four rather nasty lines on the command prompt (five, one more for c/C). I hope that it will help the developers to get this done automatically. I use docker to supply ready-to-use installation of R and Shiny to my colleagues at the hospitals, and even one line in the black box will lead to immediate ânot for usâ reactions.
docker run --privileged -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker alpine sh
# inside the created shell, you run the 2nd command:
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh
mount -t cifs //<computername>/C /C -o username=Dieter,password=yourpassword,noperm
Note: computername is the Network name of the computer.
I tried the solution from @elucas and it works for me.
1/ to be sure, change your windows password with something simple with no special chars
2/ reset your shared drive credentiel, and donât mount C:
3/ when you are prompt for login / password use : 10.0.75.1\yourusername (or 10.0.75.1\yourusername@something.com if necessary)
and your password
4/ try with the docker example : docker run --rm -v ./folderwithfiles:/data alpine ls /data
Yes. For me, there is a bug if I mount the C drive. If I check C: and E:, I canât mount volumes. But if I reset credentials, and only mount E:, it works.
I was having the same problems with volume mounts yersterday. I could resolve it with following steps:
Created a new account âdockeruserâ with [0-9a-zA-Z]+ password.
Shared drive with shared drives screen of the traybar application.
Entered 10.0.75.2\dockeruser as username and dockeruserâs password
Removed sharing of the drive in windows explorer.
Reshared the drive with docker
Now working
It seems like the ResetCredentials option is not working properly. Basically it should do the required steps including removing the shared driver status for the connected docker users. However, this is not the case. Only manually removing the shared option on the volume allowed it to be shared correctly afterwards. Iâm not sure about the account though, it might also work with your user account.
This continues to not work for me using Win10 14342, with DFW 1.11.1-beta14.
Iâve tried all of the above.
When I use: docker run --rm -v d:/:/data alpine ls -R /data
I only see a very small subset of the directories on d:, and nearly all of those that show up are empty (according to ls). Itâs interesting that I do see a couple of files a couple levels down. I have no idea why.
I do see files that were created in the container, but these donât show up in the host.
I am also having trouble getting volumes to mount. I can see the directory when listing directories in the console of the VM, but there are no contents.
The test above that others have mentioned gives no results for me.
The shared drives functionality is just too flaky to be used. It seems to be additionally impacted by connection to, or disconnection from, VPN. I find that resetting the DFW install will usually fix the problem for a while, but it always returns.
This even happens within a single docker-compose session, where a number of images are being pulled, and containers started up â it will just suddenly drop the shared drive connection, and this come to a halt.
Itâs just not ready to be used.
Itâs disappointing to not see more updates, with at least an attempt to improve things in this important area.
I think Iâm going to have to abandon the beta for a while, go back to docker toolbox, or even vagrant.
I had the same problem. Here is my solution: the firewall.
The HyperV-VM needs access to the host through tcp/ip, so maybe your firewall (or antivirus) is blocking the communication from inside the vm to outside. So just whitelist the adapter (vEthernet (DockerNAT) - Hyper-V Virtual Ethernet Adapter) in your local firewall/antivirus.
@donurks Did you do this through the Windows firewall? If so, did you use a Program, Port, Predefined or Custom rule?
It looks like I already have rules added for Hyper-V related services in my firewall.
I use the kaspersky firewall. I dont know how to configure the windows firewall correctly.
I recommend that you first check your network.
You can try to unplug or turn off your internet. After that you can disable the windows firewall, restart docker (docker traybar icon -> settings -> restart docker). Now test and reactived your firewall.
You can also try the hyper v manager to connect to your vm (username: root) and try to ping your host (10.0.75.1). If the pings works then your network is fine.
One thing I noticed: youâre mounting the share using the computer name instead of the IP addressâŠ