Attempting to use nfs synced folder with encrypted folder could be handled better

[jschroeder9000]

I recently had a frustrating experience attempting to use the nfs option for synced folders. The source of that frustration ultimately was not vagrant's fault, but I feel a couple things could be done that would have mitigated it. As the title indicates, the source of that frustration was trying to use nfs synced folder with an encrypted folder. Apparently when configuring my Kubuntu install I elected to encrypt my home directory and I did not recall this, nor was I aware that this would cause issues with nfs. Again, not vagrant's fault, but I think my frustration could have been mitigated.

First, documentation. If the documentation at vagrantup.com had mentioned that nfs can not work in encrypted folders I might have checked for that before I started to lose my patience.

Second, error handling. The error I get from vagrant is that the mount command failed with non-zero exit status. And when I try to run the mount command from within the vagrant box, the error I get is 'access denied by server'. Since I was not already familiar with setting up nfs shares, I followed several leads to dead ends before realizing that exportfs -ra outputs exportfs: /home/john/foo does not support NFS export (and there were several more leads with dead ends before realizing the cause of that was an ecrypted folder). This seems like something that vagrant should be able to pick up on and report before trying to mount the nfs share.

Third, checking for this specific use case. I admit this is a bit of an edge case and this suggestion feels like a long way to go for it, but I thought I'd throw it out there anyway. My home directory is encrypted with ecryptfs and the telltale sign of it is a .ecryptfs file in /home. Vagrant could check for such a file in the current directory and all parent directories and report that to the user.

[mitchellh]

I think the best place to make this change would be the docs. If Vagrant could detect and warn, that'd be icing, but I don't have an easily setup machine to figure out all the strings that Vagrant would need to look for right now.

I'll update the docs. Thanks for finding this.

[mitchellh]

I think the best place to make this change would be the docs. If Vagrant could detect and warn, that'd be icing, but I don't have an easily setup machine to figure out all the strings that Vagrant would need to look for right now.

I'll update the docs. Thanks for finding this.

[publicus]

This would be hugely appreciated -- I spent hours yesterday trying to get vagrant to share a folder, going through firewall settings, trying many mountpoints, etc., until I realized today that the common culprit was that I was trying to mount folders within my home directory (protected with ecryptfs, but on openSUSE). Then I found this issue report, which probably would have saved me some time in the first place : /

In case it's helpful for the docs: The error message that NFS passes back in this case isn't particularly informative: "mount.nfs: access denied by server while mounting..." Running systemctl status -l nfsserver.service will show a log entry that mentions the filesystem possibly not being supported, but doesn't go into further detail than that.

[publicus]

This would be hugely appreciated -- I spent hours yesterday trying to get vagrant to share a folder, going through firewall settings, trying many mountpoints, etc., until I realized today that the common culprit was that I was trying to mount folders within my home directory (protected with ecryptfs, but on openSUSE). Then I found this issue report, which probably would have saved me some time in the first place : /

In case it's helpful for the docs: The error message that NFS passes back in this case isn't particularly informative: "mount.nfs: access denied by server while mounting..." Running systemctl status -l nfsserver.service will show a log entry that mentions the filesystem possibly not being supported, but doesn't go into further detail than that.

[mitchellh]

Fixed docs :)

[mitchellh]

Fixed docs :)

[publicus]

Thank you! : )

On July 7, 2015 1:19:58 AM EDT, Mitchell Hashimoto notifications@github.com wrote:

Closed #4987.

---

Reply to this email directly or view it on GitHub:
mitchellh#4987 (comment)

[publicus]

Thank you! : )

On July 7, 2015 1:19:58 AM EDT, Mitchell Hashimoto notifications@github.com wrote:

Closed #4987.

---

Reply to this email directly or view it on GitHub:
mitchellh#4987 (comment)