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
Attachment:
pgpf_A3Z0BkCy.pgp
Description: PGP signature