|
|
I thought I'd share my recent exploits getting NetBSD sharing files on my
MacBook Pro.
I'm running NetBSD inside of both a Parallels and a VMware Fusion VM. I
started with Parallels, and I'm a little more comfortable with their GUI.
I use Fusion as it supports SMP on the clients.
The frustration I've run into is that I need a certain amount of space in
a VM to build, but I don't need all that space all the time. And since the
laptop's hard disk isn't THAT big, I'd like to not waste space. This is
the classic problem with static allocations.
So I thought about using a network file system. I know the Mac supports
Windows networking, and we support smbfs. I thought that'd be the perfect
solution!
Turns out it's not. smbfs doesn't support hard links, so builds are weird.
:-(
So I decided to look into NFS. My initial concern was that all the NFS
admin stuff I've seen is in the server management tools, and this laptop
is running Desktop. It turns out, however, that, as
http://macresearch.org/nfs-exports-leopard , shows, it's really easy to do
in Leopard. Just create an /etc/exports and run "nfsd update" to cause it
to catch changes.
I did run into two issues that had me scratching my head for a while. They
both involved the fact I'm using "Shared" networking, where the respective
application is doing its own NAT for me.
Issue #1 is that neither Parallels nor Fusion seem to correctly support
talking to a service running on the "Shared Net" host IP address. i.e. if
I ssh into the NetBSD VM and it sees a TCP connection from 10.211.55.2 <->
10.221.55.3 (the latter being its IP), I can't talk to an NFS server at
10.221.55.2. The NAT just doesn't work out right.
What, however, DOES work is to remember that both products also support
"Host-only" networking. The important thing is that it's a host-local-yet-
world-routable (i.e. not 127.0.0.1) IP. So what I ended up doing is
pointing the NFS mounts at the "Host-only" IP address for the respective
product. It doesn't matter which one I chose, other than that the address
might only work if that given product is running (if I point the NetBSD in
the Fusion VM at the Parallels address, I may need to have Parallels
running for this Fusion VM to fully function). I'm not sure, but I have no
inclination to find out. :-)
Issue #2 was that the mounts would always fail saying I didn't have enough
privilige to perform the mount. I.e. I was using a non-priviliged port.
The weird thing that stumped me is that NetBSD gets this right by default.
Complicating things was that I couldn't get tcpdump to capture the packets
that Mac OS was seeing.
The answer is that the connections, even UDP, are getting NATed, and the
NAT was changing the port # to something not in the reserved space. Fix
was:
# cat > /etc/nfs.conf
nfs.server.mount.require_resv_port = 0
^D
and I think I needed an nfsd update too.
Oh, our NFS implementation didn't like the dircookies Leopard gave it, so
I enabled -32bitclients on the exports, and all was silent.
The last little trick I tried was to limit my exports to just the VM
systems. I found the easiest way to do this was to just limit my exports
to the VM nets:
# cat /etc/exports
/Volumes/XX/Sharing -maproot=root -sec=sys -network 10.211.55.0 -mask
255.255.255.0 -32bitclients
/Volumes/XX/Sharing -maproot=root -sec=sys -network 10.37.129.0 -mask
255.255.255.0 -32bitclients
/Volumes/XX/Sharing -maproot=root -sec=sys -network 192.168.33.0 -mask
255.255.255.0 -32bitclients
/Volumes/XX/Sharing -maproot=root -sec=sys -network 192.168.139.0 -mask
255.255.255.0 -32bitclients
The corresponding fstab entries are:
Parallels:
10.37.129.2:/Volumes/XX/Sharing /sharing nfs rw 0 0
Fusion:
192.168.139.1:/Volumes/XX/Sharing /sharing nfs rw 0 0
Hope y'all enjoy!
Take care,
Bill
|
|