Changing permissions on an NFS mount + sharing directories with a guest VM

Question

I'm building a development environment where folders from a host environment (OSX) are mounted in VirtualBox VMs running Ubuntu guests.

Our experience is that straightforward VirtualBox shared directories are too slow, so we've typically done this by mounting the directory as an NFS mount within the guest. Real-time editing from the host environment is a requirement.

The problem with this is that operations like chown and chgrp fail, and we need to replicate something close to our production environment (e.g. www-data owning the files used by Apache).

bindfs looked like a promising possibility:

bindfs - mirrors or overlays a local directory with altered permissions

But it doesn't seem to be possible to change permissions with native unix utilities and system calls. This won't work for me, as I need to integrate with existing configuration management systems (Salt, Puppet) that provision the boxes.

Is there some other way to get an NFS mount to look like a regular directory as far as permissions go? Or another alternative for mounting a directory into a VirtualBox VM?

EDIT: Here is the output of mount:

192.168.34.1:/Users/$me/src/states /etc/apps/state type nfs (rw,vers=3,addr=192.168.34.1)
192.168.34.1:/Users/$me/src/apps on /srv/apps type nfs (rw,vers=3,addr=192.168.34.1)

When I say that changing permissions 'fails', I mean that I get "operation not permitted" errors.

For example:

$ ls -l /srv/www
total 8
drwxrwxr-x 4 501 dialout 136 May 31 16:20 default_vhost
drwxrwxr-x 5 501 dialout 170 May 31 16:20 default_vhost_ssl
$ chown root /srv/www/*
chown: changing ownership of `/srv/www/default_vhost': Operation not permitted
chown: changing ownership of `/srv/www/default_vhost_ssl': Operation not permitted

Solution

Only root may use chown. NFS or not, you need to run chown as root.

By default, NFS maps the local root user to the remote user nobody. This makes chown impossible to use, you would have to run it on the server. If it's ok for the client-side root to have root powers on the NFS filesystem, export the filesystem with the no_root_squash option. That is, on the server, in /etc/exports, you should have something like.

/Users/$me/src/states 192.168.34.2(no_root_squash,async)

Comments

[gertvdijk]

Please share more on the NFS configuration you used (both client and server-side). Permissions and ownership should just work using NFS, but you probably want to configure it with NIS have user/group IDs in sync. "operations like chown and chgrp fail" Please include how this fails. (what is the error message? what is the result instead? etc.)

[Cera]

Apologies that it wasn't clear. I've just edited the question to add some more detail.

[Cera]

Will this mean that chown operations on the client will take affect on the host system? I was hoping to use something like bindfs, where permission bits in the client only take affect there.

[Gilles 'SO- stop being evil']

@Cerales NFS gives you remote access to a filesystem. It has some limited provisions for shuffling around user IDs, but apart from that, permissions are the same on both sides. That's what you asked for: “get an NFS mount to look like a regular directory as far as permissions go”. If you need a different view of permissions on the two sides, bindfs does it in a limited way. Maybe a union filesystem can make “permission bits in the client only take [e]ffect there”, but then that contradicts your question, so I suspect you need to clarify your goals before looking for a way to accomplish them.

[Cera]

Thanks for clarifying things more. I meant that I wanted it not to have any relationship to the permissions on the host system - I didn't realise that NFS was purely remote access, with shared permission bits. bindfs would be great if it standard tools like chmod worked with its permissions. I'll have to look into other ways to setting up a share, I think.