-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support system NFS as an alternative to UNFS3 #274
Labels
Comments
This was referenced Apr 5, 2018
fyi. This docker-machine-nfs settings respect changes for nodejs events. noacl,async,nolock,vers=3,udp,noatime,actimeo=2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is discussion about this scattered around lots of different issues so I'll try to consolidate it here. Dinghy doesn't use MacOS system NFS because the system NFS server doesn't allow nested exports -- in other words, if you export
/Users/me
, you can't also export/Users/me/some-other-project
. This is a problem for me and some other people, because we have projects using Vagrant with NFS shares, and so exposing the whole home dir breaks those Vagrant projects.But for those who don't care about that use case, the system NFS server is faster (and probably less prone to issues). I don't plan on adding support myself since I wouldn't use it, but I'm open to somebody else tackling this addition. You'll need to be very careful to lock this down so you aren't exposing the user's entire home dir over NFS to others on the LAN. docker-machine-nfs may make this easier, I haven't looked at it closely.
Alternatively, it may even be possible to have a daemon listening for Docker events and sharing only specific folders over NFS when they are mounted via Docker, but I suspect it would be difficult to get that working reliably and transparently.
The text was updated successfully, but these errors were encountered: