Document extra requirements for netfs on windows

[glinton]

[nanobox config] Using netfs on windows doesn't always work right out of the box. We should either suggest native or explain the steps to enable cifs so netfs will work.

[lyondhill]

Need more information on how the cifs might fail and more testing to reproduce.

[NOA-Louis]

I'm on Windows 10, I had exactly the same issue and same outputs as that one on Slack: https://nanoboxio.slack.com/archives/C2EUZNV2T/p1499091327993469.
It was keep failing the Mounting codebase.
The output for the nanobox config ls was this one:

{
  "provider": "docker-machine",
  "ci-mode": false,
  "mount-type": "netfs",
  "netfs-mount-opts": "mfsymlinks",
  "cpus": 2,
  "ram": 2,
  "disk": 102400,
  "external-network-space": "192.168.99.50/24",
  "docker-machine-network-space": "172.21.0.1/16",
  "native-network-space": "172.20.0.1/16",
  "ssh-key": "default",
  "anonymous": false,
  "lock-port": 12345
}

Then @glinton asked me to do the following command: nanobox config set mount-type native. And it's working fine now, which means the mount type was not defined.

[glinton]

In case the slack message referenced gets truncated, the error output from NOA-Louis was:

Preparing environment :
  ! Mounting codebase
  ! Mounting codebase
  ! Mounting codebase
  ! Mounting codebase
  ! Mounting codebase

Error   : failed to add share exit status 2
Context : failed to init docker client -> failed to setup env mounts -> failed to mount the code share on the provider -> failed to add share

It seems to be the same issue as originally reported, where somewhere in Windows 10, the shares/sharing is disabled or something. The workaround, as louis mentioned, is to set the mount-type to native to circumvent the cifs/share/netfs issue

[danhunsaker]

Oh. Uh. I have a suspicion about this one...

When Windows connects to a new network, it asks the user whether or not to treat that network as a Public or Private (Home/Work) one. If the user selects Public, most network services will be disabled on that interface, including CIFS.

The fix, if my suspicion pans out, is to change the network type to Private, thereby allowing those services to be exposed on that interface. We might even be able to do this programmatically, if it turns out to be the culprit.

[tylerflint]

@danhunsaker Wow, that is great insight. Very cool if this ends up being the case.

[lyondhill]

yah that is a great idea. I can test it on my machine now that im back home.

[lyondhill]

@danhunsaker I changed my network to public and I am still able to connect to my shares.
@NOA-Louis can you look to see if your network is set to public or private?

[danhunsaker]

Note that each network has its own setting for this, so you'll want to check what it is for each adapter, and specifically the TAP device created by/for nanobox-vpn.

[danhunsaker]

In order to diagnose this properly, we're going to need a lot more information than we have. So, anyone reading this is encouraged to chime in with the settings on their system so we can compare and contrast what works with what doesn't.

• Windows version (with build number if available)
• The values of the settings in Control Panel → Network and Internet → Network and Sharing Center → Advanced sharing settings; there are three sections, and it only opens one at a time, so be sure to get them all...
• Enabled drivers on the Nanobox TAP interface (Control Panel → Network and Internet → Network Connections and then right-click the interface and choose Properties; if you have more than one TAP interface, you can provide them all, but if you can narrow down which one is used by Nanobox, that's the one we care about...)
• Network Profile on the Nanobox TAP interface (Settings → Network & Internet → Ethernet and then select the interface from the list; this is mostly just to confirm my initial hunch was wrong, but also useful data to have)
• The output of ipconfig /all and route print
• The output of net share

We may ask for additional info at a later date, but for now, this should be more than enough to start on.

[NOA-Louis]

@lyondhill private network.

[danhunsaker]

@NOA-Louis He's saying it didn't stop working when he switched to Public. I'm not 100% certain which interface was switched, in this case, but @lyondhill is smart enough to know it has to be the one Nanobox uses, so I'm pretty sure it's not just Public/Private. I think it's actually the setting to enable file sharing in the first place, which is among the options I listed as wanting to see, above.

I'd love to see what you have for each of those values, in fact!

[lyondhill]

@danhunsaker I did set the one nanobox uses. then I saw your message and thought it best to double check. Now all my networks on my windows machine are set to public :)