docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.85k stars 285 forks source link

Shared Drives are gone after reboot of Win10 #3083

Closed frosch95 closed 5 years ago

frosch95 commented 5 years ago

Expected behavior

After reboot the Win10 machine, The net shares should not disappear.

Actual behavior

After reboot of the Win10 machine, the net shares are available until docker is started and then they are gone.

Information

We have a special Network that has to be set to stop firewall blocking (172.31.31.0/255.255.255.0). This Network is configuredin the settings and is still available after reboot.

When the shares are not available after reboot, I can change the network to something else (e.g. 172.31.30.0) and switch back to 172.31.31.0 after the restart of docker engine when applying the correct network, the shares are available.

Is it maybe a startup issue? Maybe when docker starts to create the shares the first time and try to test them it uses the default 10.0.75.0 network which is blocked by our firewall and the network is switched to 172.31.31.0 after mounting the shares failed?

jasimancas commented 5 years ago

Same error here in Windows Server 2019. Version 2.0.0.0-win82 (29268) Engine: 18.09.0

To repair this, I click in taskbar and settings, go to "Shared Drivers" and click in Apply directly, restart containers and all work fine again.

frosch95 commented 5 years ago

My fix is a bit different than yours. The apply button is inactive and removing/changing the checkboxes and clicking apply shows the firewall error message.

The only way for me to get this work is changing the IP, save, change back, save again.

slav4ik51493 commented 5 years ago

My fix is a bit different than yours. The apply button is inactive and removing/changing the checkboxes and clicking apply shows the firewall error message.

The only way for me to get this work is changing the IP, save, change back, save again.

Did you changed IP in settings of docker?

frosch95 commented 5 years ago

ashampoo_snap_donnerstag 31 januar 2019_02h55m17s_002_

slav4ik51493 commented 5 years ago

But why you use 172.31.31.0 instead default 10.0.75.0? Is it random IP or it's something else?

slav4ik51493 commented 5 years ago

image End also, I can't entry "172.31.31.1" into "Subnet Address"

frosch95 commented 5 years ago

Have you read the Information section?

The 172.31.31.0 is a special subnet which is not blocked by our local installed desktop firewall (and I can not change this!). So this is the only available default I can use for the virtual switch.

Every other subnet is blocked!

So fine, I can change the network to 172.31.31.0 and everything is working as long as I do not reboot.

After a reboot the docker network is not reachable.

When changing the network settings to something else (not working as it is not supported by our companies desktop firewall) like 172.31.30.0 enables the Apply button and I can press it (leaving the initial 172.31.31.0 does not enable the button).

So I have to Apply a not working network to get the possibility to change the network back to the working 172.31.31.0 and Apply that again. After I have done that the docker network is reachable.

Every time I reboot my desktop I have to do this procedure. And every Apply does a docker restart which takes quite a while.

So something happens when pressing Apply in the network settings that gets the docker network working, which does not happen after a reboot and the docker starts initially .

slav4ik51493 commented 5 years ago

Oh, sorry, I haven't read the Info section. Thank you for reply, will war with my IT section of Company for solving this problem

slav4ik51493 commented 5 years ago

I solved my problem by adding new rule to VipNet client...

frosch95 commented 5 years ago

I could not change the VPN rules. They are managed by the companies IT. The "trick" with changing the IP address and changing the address back is a hint, that is must not be done in the VPN Software. I have no clue what is the difference between starting docker and the automatical restart of docker after network changes.

docker-robott commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

docker-robott commented 4 years ago

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle locked