Vagrant: Can't get NFS to work on Ubuntu 16.04

[octoxan]

Vagrant version

1.9.1

Host operating system

Ubuntu 16.04

Guest operating system

Ubuntu 14.04 (Scotchbox) https://github.com/scotch-io/scotch-box

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

    config.vm.box = "scotch/box"
    config.vm.network "private_network", ip: "192.168.33.10"
    config.vm.hostname = "scotchbox"
    #config.vm.synced_folder ".", "/var/www", :mount_options => ["dmode=777", "fmode=666"]

    # Optional NFS. Make sure to remove other synced_folder line too
    config.vm.synced_folder ".", "/var/www", :nfs => { :mount_options => ["dmode=777","fmode=666"] }

end

Debug output

Here is the entire debug output:
https://gist.github.com/octoxan/436aad239d306ad4cae39f34632a546c

My final error is

mount.nfs: access denied by server while mounting 192.168.33.1:/home/xander/Websites/scotchbox

I do have nfs-common installed on the vm and nfs-kernel-server installed locally.

Any ideas on how to fix this?

[Yoshiitsune]

Same problem with vagrant 1.9.2 on Arch linux

[kivoli]

I may at least offer some insight as to why and maybe a work-around acceptable for most people. When using NFSv4, which I unfortunately require due to Ruby bundler using file system locks, Ubuntu somehow enforces the prerequisite of a “root” export for NFS.

So this would work:

/home/testuser 192.168.121.0/24(rw,fsid=0,no_subtree_check,sync)
/home/testuser/project 192.168.121.0/24(rw,nohide,no_subtree_check,sync)

```sh
mount 192.168.121.1:/project /vagrant

The idea is that all folders to be exported via NFS should be bind-mounted to a single folder structure (usually `/exports`). [Ubuntu NFS Guide](https://help.ubuntu.com/community/SettingUpNFSHowTo)

Funnily enough the way Vagrant does it works perfectly fine with Debian Stretch so it’s not strictly enforced by NFSv4.

Work around for people who do not need NFSv4: [Use NFSv3](https://www.vagrantup.com/docs/synced-folders/nfs.html)
```Vagrantfile
config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_version: 3

PS: I first suspected AppArmor but turning it off didn’t change the outcome. :-(

[kivoli]

Using Wireshark I now found out that the “Access denied” occurs when the client (debian/jessie64 in my case) tries to access the parent folder of the folder to be mounted:

Note: “tester” is the user name and the path I try to mount in Vagrant is 192.168.121.1:/home/tester/project.

After adding read only access to this parent folder it works, even if it’s not fsid=0 — that’s where I was mistaken earlier.

"/home/tester" 192.168.121.0/23(ro,no_subtree_check,all_squash,anonuid=1000,anongid=1000,fsid=2222222222)
"/home/tester/project" 192.168.121.0/23(rw,no_subtree_check,all_squash,anonuid=1000,anongid=1000,fsid=3339204725)

This is not desirable and as I stated before, for some reason it is also not necessary on Debian Stretch. Upgrading nfs-kernel-server to the version in Stretch did not help, however. I’ll keep investigating.

[kivoli]

A small update from my side. Three patches to mountd back in 2009 [1][2][3] enabled it to create “pseudo exports” for the parents of an exported directory if an explicit pseudo root (fsid=0) was not set and hide it to showmount -e. This works as expected on Debian Stretch; I can actually mount /, /home, /home/user, etc. but they only show content I have access too, e.g.:

~$ mount -o vers=4 192.168.121.1:/ /vagrant
~$ find /vagrant
/vagrant
/vagrant/home
/vagrant/home/user
/vagrant/home/user/project
/vagrant/home/user/project/fileA
/vagrant/home/user/project/fileB
/vagrant/home/user/project/Vagrantfile

For some reason Ubuntu 16.04 apparently doesn’t do that.

[kivoli]

Eureka! In hindsight it’s so easy and clear to see what the “problem” is:

user@debian ~$ ls -lh /home
drwxr-xr-x 33 user user 4,0K Mar 16 19:35 user
tester@ubuntu ~$ ls -lh /home
drwx------ 22 tester tester 4,0K Mar 16 19:28 tester

A simple chmod a+rx /home/user “fixes” the problem. IMO this is a bug in the way mountd creates the pseudo roots by ignoring anonuid and anongid thus causing this permission issue but that’s their problem and not Vagrant’s.

@octoxan I recommend to close this ticket. I’ll try to reach out to the nfs-utils devs to discuss a solution.

[chrisroberts]

Closing via https://github.com/mitchellh/vagrant/issues/8279#issuecomment-287154046

[Aloz1]

At the very least, this needs to be documented. I've just been bitten by the same issue.

However, I'm of the opinion that adding +rx to /home/ is not an appropriate solution (a publicly readable home directory could be dangerous). I suspect the reason this has worked in the past, and now does not, or works in some distros but not others, is to do with how security conscious the distros' maintainers are.

I'm not convinced this is a mountd bug (although documentation is definitely lacking). The purpose of all_squash is to map the uid/gid of a connecting client to anonuid/anongid _subdirectory_ of an NFS system. If that were also applied to all parent directories, there could be bad consequences.

As an example you may have the exported directory '/a' with subdirectory '/a/b'. Lets say '/a' allows read access for all, but only write access to those of group foo, and that '/a/b' is exported with all_squash with read/write access to the anonuid/anongid. If anonuid/anongid were applied to, clients accessing all parent directories as well, clients in the 'foo' group would no longer have write access to '/a'. Although not relevant when exclusively using vagrant, this is a valid scenario.

I think one of the following may be more appropriate for vagrant:

• Add an export for one of '/', '/home' or '/home/__' which adds all_squash.
• Detect the deepest common directory being exported and set its fsid=0
• Follow the general consensus of bind mounting to a default/predefined export directory which has fsid=0 (maybe a sane default could be /exports/vagrant).

[Aloz1]

As an aside (mostly for future reference for those that stumble upon this thread), here's @kivoli's discussion on the NFS mailing list: https://marc.info/?l=linux-nfs&m=149001321801612

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.