tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

File sharing adventures with NetBSD and Parallels

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 

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 , 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 <-> (the latter being its IP), I can't talk to an NFS server at 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 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 

# cat > /etc/nfs.conf 
nfs.server.mount.require_resv_port = 0

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 -mask -32bitclients 
/Volumes/XX/Sharing -maproot=root -sec=sys -network -mask -32bitclients 
/Volumes/XX/Sharing -maproot=root -sec=sys -network -mask -32bitclients 
/Volumes/XX/Sharing -maproot=root -sec=sys -network -mask -32bitclients 

The corresponding fstab entries are:

Parallels: /sharing nfs  rw          0 0

Fusion: /sharing nfs  rw          0 0

Hope y'all enjoy!

Take care,


Attachment: pgpf_A3Z0BkCy.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index