Sharing folders via MacOSX NFS server -> Ubuntu Client uid problem

[Patrick Debois]

Hi list,

we're slowly moving away from shared folders to NFS shares because of both the performance and the instability on writes.
Depending on the hostname of the client we're switching to nfs or not (FYI see below)

- We've activated the flag :nfs => true with the share_folder
- added a hostonly network
- installed an nfs client in the vm
- vagrant reload

and yes:
-  the NFS shares are available in the machine (Ubuntu 10.10)
- the exports file is written succesfully

Our problem is that the directories inside the VM are owned by uid/gid 501
And our vagrant user inside the machine is uid 1000.

We've tried playing around with
  #config.nfs.map_uid=1000
  #config.nfs.map_gid=1000

But these seem to influence the nfs server (MacOSX based) to write files that come from clients with those userpermissions.

What I'm looking for is mapping the uid 501 I get from the share to an uid inside the vm. This is probably ubuntu related , but I'm hoping you people have come across a similar setup.

Thanks for your help

Parick

---

Snippet from our vagrantfile

  nfs_hosts=%w(falcon-pdb-not)

  # Switching to NFS for development machines
  require 'socket'
  my_hostname=Socket.gethostname.split(/\./)[0]
  if nfs_hosts.include?(my_hostname)
        share_flags={:nfs => true}
  else
        share_flags={}
  end

  # Map our local user to the vagrant user in the box
  #config.nfs.map_uid=1000
  #config.nfs.map_gid=1000

  config.vm.share_folder "datastore", "/home/vagrant/datastore", "./datastore", share_flags
  config.vm.share_folder "dashboard", "/home/vagrant/dashboard", "./dashboard", share_flags

[jasherai]

> ------------------------------------------------------------------------

> Snippet from our vagrantfile
>
>    nfs_hosts=%w(falcon-pdb-not)
>
>    # Switching to NFS for development machines
>    require 'socket'
>    my_hostname=Socket.gethostname.split(/\./)[0]
>    if nfs_hosts.include?(my_hostname)
>          share_flags={:nfs => true}
>    else
>          share_flags={}
>    end
>
>    # Map our local user to the vagrant user in the box
>    #config.nfs.map_uid=1000
>    #config.nfs.map_gid=1000
>
>    config.vm.share_folder "datastore", "/home/vagrant/datastore",
> "./datastore", share_flags
>    config.vm.share_folder "dashboard", "/home/vagrant/dashboard",
> "./dashboard", share_flags

Hi Patrick,

It looks like the map_uid/guid id's are used on the nfs SERVER to map
requests to the server id's (https://github.com/mitchellh/vagrant/blob/
master/templates/nfs/exports_linux.erb#L3).

Perhaps you could try using mapping to uid/gid=501 (Your mac user
uid) . This should then work, as the all_squash option used by vagrant
for exporting the share should map all requests from the client to the
nobody user (which you have remapped to 501).

HTH, and that I understood your issue correctly...

jasherai

[Patrick Debois]

Hi Jasherai,

thanks for trying to figure out my problem.
Unfortunately the mapping your are suggesting is the default vagrant does.

HOST (MacOSX 10.6) - VM (Ubuntu 10.10)
uid (is 501) show here as 501 but would
like it to look as 1000

The config.nfs.map settings only change things on the HOST side, not on
the VM side.

Another route would be to use bindfs, anyone experience with that?

[Mitchell Hashimoto]

Patrick,

On Mon, Mar 14, 2011 at 4:44 AM, Patrick Debois
<patrick...@gmail.com> wrote:
> Hi list,
>
> we're slowly moving away from shared folders to NFS shares because of both
> the performance and the instability on writes.
> Depending on the hostname of the client we're switching to nfs or not (FYI
> see below)
>
> - We've activated the flag :nfs => true with the share_folder
> - added a hostonly network
> - installed an nfs client in the vm
> - vagrant reload
>
> and yes:
> -  the NFS shares are available in the machine (Ubuntu 10.10)
> - the exports file is written succesfully
>
> Our problem is that the directories inside the VM are owned by uid/gid 501
> And our vagrant user inside the machine is uid 1000.

This is not a bug.

NFS works by simply shuttling files and metadata over from server to
client, which means permissions can't be changed mid-way. I've
configured NFS by default to the common-case, which is that even
though the uid/gid is 501/20, every user on the VM should be able to
write to it (go ahead, try it!).

In practice, this has never been a problem for serving any web applications.

Best,
Mitchell

[Patrick Debois]

Hi Mitchell, I wasn't referring to a vagrant bug. All due to a lack of
understanding on my side.

You (as always) are correct again. Even though the mounted directories
will list permissions not able to write by the vagrant users.

When I actually try it (as your wisdom suggested) it works! So I guess
problem is solved.

Still wonder how; is it NFS mount ignores the filesystem permissions
somehow?

Thanks for clarifying that.

Patrick

[Mitchell Hashimoto]

Patrick,

On Mon, Mar 14, 2011 at 12:10 PM, Patrick Debois
<patrick...@gmail.com> wrote:
> Hi Mitchell, I wasn't referring to a vagrant bug. All due to  a lack of
> understanding on my side.
>
> You (as always) are correct again. Even though the mounted directories will
> list permissions not able to write by the vagrant users.
>
> When I actually try it (as your wisdom suggested) it works! So I guess
> problem is solved.
>
> Still wonder how; is it NFS mount ignores the filesystem permissions
> somehow?
>

I'm not sure how familiar you are with linux filesystem
implementation, I'm certainly an amateur, but I have written one or
two for fun (basic stuff like automatically extracting MP3 ID3 tags
and other "for the lulz" things), but I can explain this for you :)

The permissions reported by "la -al" or so on are gathered via the
"stat" syscall. This stat syscall will call into a callback into the
filesystem implementation, which returns a permission. Same when
opening or writing to a file, it goes through filesystem callbacks.

So even though the filesystem may report that you can't write, this is
enforced at the FS-level instead of the OS-level, which means that
although NFS reports the perms correctly with regards to the host
system, it doesn't enforce them because of my configuration.

Make sense? :) Random facts. "The More You Know"
(http://thegurglingcod.typepad.com/thegurglingcod/images/2008/02/12/the_more_you_know2.jpg)

Best,
Mitchell

[Folken Laëneck]

Hi Patrick,

Le lundi 14 mars 2011 14:16:19, Patrick Debois a écrit :

> Another route would be to use bindfs, anyone experience with that?

You can find a Vagrant plugin that make bindfs directly usable from Vagrantfile on RubyGems : http://rubygems.org/gems/vagrant-bindfs

I wrote it a few month ago and use it on a daily basis on Linux. Alas, I failed to make it work with an OS X host. It seems that HFS(+) partitions are not compatible with bindfs : write permissions are losts as soon as the folder is binded. But maybe I just didn't try hard enought.

Hope this helps you,

Folken Laëneck.