Improve configuration/clean-up of the /etc/exports file

[tonivdv]

The configuration and cleanup of the /etc/exports file should be improved. Using the technique of Vagrant could be a good approach:

# VAGRANT-BEGIN: 21171 5b8f0135-9e73-4166-9bfd-ac43d5f14261
"/path/to/vagrantfile" 172.28.128.5(rw,no_subtree_check,all_squash,async,anonuid=21171,anongid=660,fsid=3382034405)
# VAGRANT-END: 21171 5b8f0135-9e73-4166-9bfd-ac43d5f14261

We should probably use the docker-machine name and would be something like:

# DOCKER-MACHINE-NFS-BEGIN: machine-box
/Users 192.168.99.100 -alldirs -mapall=501:20
# DOCKER-MACHINE-NFS-END: machine-box

Things to keep in mind:

• What when ip changes? (docker-machine does not provide fixed ip at this moment of writing)
• ... ?

[ogizanagi]

Using the whole network should do the trick. Here is what I use manually:

# /etc/exports

"/Users/Ogi" -alldirs -mapall=Ogi -network 192.168.99.0 -mask 255.255.255.0

[tonivdv]

@ogizanagi Can you elaborate what this does, and how it improves it all?

[ogizanagi]

It'll allow you to not care about docker-machine ip, which would be in the whole 192.168.99.0/24 range anyway, by allowing any IP from this network to mount the given /Users/Ogi NFS share.

[tonivdv]

@ogizanagi Ok I see. That could indeed be much easier approach. What are the downsides according to you, if any?

[ogizanagi]

Actually I don't know any downside, but I'm not a system expert :)
This is the configuration used at SensioLabs/Blackfire. You can find a great post about it here: http://blog.blackfire.io/how-we-use-docker.html (Now have to be tweaked for docker-machine, but that's the exact same thing)

[tonivdv]

Thanks for the article. I'll investigate the -network option. Now I'm almost done with #17 , which automatically adds a solution for this too.

[ckortekaas]

For what it's worth adding an entire C class (even private) subnet isn't such a great idea for some use cases. For example my organisation uses the entire private ranges up, 192., 10. and 172.* (a large university). So if the default sharing behaviour was this wide it could open up a share far too much for developers who don't understand networking very well.

Also it seems like docker-machine doesn't seem to change the ip between restarts, even though it warns you it might. Even destroying the vm and creating a new one seems to reuse the same ip every time.

[tonivdv]

For what it's worth adding an entire C class (even private) subnet isn't such a great idea for some use cases. For example my organisation uses the entire private ranges up, 192., 10. and 172.* (a large university). So if the default sharing behaviour was this wide it could open up a share far too much for developers who don't understand networking very well.

That's what I was afraid off.

Also it seems like docker-machine doesn't seem to change the ip between restarts, even though it warns you it might. Even destroying the vm and creating a new one seems to reuse the same ip every time.

Unfortunately that's not the case :( ! Assume you created and start a 'machine', you will be default get the ip 192.168.99.100 . If you create and start another machine, it will get 192.168.99.101. If now you stop both, and you first start the second created machine, it will now get the ip 192.168.99.100 .

I got this a lot but found a work around while reading issue docker-archive-public/docker.machine#1709:

192.168.98.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.98.1/24" m98

192.168.97.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.97.1/24" m97

192.168.96.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.96.1/24" m96

If there's no other machine with the same cidr, the machine should always get the .100 IP upon start.