(UPDATE: A reader has pointed out that the specific problem that I was trying to address is actually solvable using another workaround. Due to bugs in VirtualBox shared folders handling symlinks, they were actually disabled on purpose…and no check box was provided in the UI to turn them back on. But if you’re a “risk taker” and have read the issues and don’t think they affect you, you can use VBoxManage to enable it on a case by case basis…for particular shares in a particular VM.

So if you go to the directory where your virtual machine lives, and the VM name is VM_NAME with your share named SHARE_NAME, you just need to type:

VBoxManage setextradata VM_NAME
VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1

That turns shared links back on, for that VM and that share. And if you don’t know how to mount VirtualBox shares from within the client in read/write, in my case you have to specify your user id as MY_ID in the following way:

 
sudo mount -t vboxsf -o uid=MY_ID,rw share /path/to/share

In my basic tests, this seems to work. If anyone has insights into what the actual dangers to doing this are, please add a comment.)

Before I mentioned how I had moved from VMWare to VirtualBox, so that more of the stack I use would be open source. Besides the “Genuine Windows” VM re-activation annoyance I mention (due to a perceived hardware change), everything seemed to go fine after that.

A couple months later I hit a snag. In my configuration I wanted to keep certain project directories on the host…and be able to read and write those directories in the guest. I expected to be able to use the “Shared Folders” feature, which does exactly this. It’s built into VirtualBox:

But eventually I ran into a problem…

VirtualBox shared folders don’t support the creation of symbolic links by the guest in a directory owned by the host. Not even if the underlying file system on the host supports them..

How to work around this? Networked filesystems were one answer, but have never been something I looked at favorably. They’ve always seemed overly complicated to set up, and platforms pull support for any given one at the drop of a hat. Plus, they offer ridiculously opaque error messages which give you no indication of what setting you might tweak to make them work.

So despite being the type of person who snarls at people who back up source code with zip files and demand they learn to use version control, I’ve been a luddite when it comes to networked filesystems. Rather than go through the pain of setting them up, I’d frequently resort to zipping up a directory…putting it on a ftp server…then downloading it to the other computer! :-/

But zipping the problem away wasn’t going to be an option in this case. So it was time to bite the bullet. I’m going to explain how I set up NFS on an OS/X host with a Debian VM.

(more…)

Somehow I made it up to 2007 without ever writing code that opened a raw network connection or pulled apart a TCP/IP packet. Naturally, I had some hand-wavy notions of more-or-less what was going on under the hood—in college I took a 400 level CS course based on an old edition of Tanenbaum’s excellent Introduction to Computer Networks. But our homework was all theoretical, and I didn’t delve very deeply into the practicality of what powers our modern Internet.

But this year I was tasked to port some Windows networking code to Linux and OS/X. Looking at what was there, I guessed it was no big deal and said I’d do it. After all…there is a layer of abstraction known as “Berkeley sockets” which is practically identical to the UNIX API for reading and writing files. How hard could it be to recompile that on a new platform?

Though sometimes it might not be that hard, this case turned out to include the functionality of a DHCP server. The Windows version was able to work at the socket level by broadcasting UDP packets to 255.255.255.255, but the OS/X and Linux versions fundamentally couldn’t do it this way. Their semantics are different for how the socket calls are translated into packets.

I want to talk about some of the high-level gotchas to watch out for if you’ve just never run up against these particular dark alleys. Because I’m talking about “weirdness” only, I’m not going to explain basic mundane socket programming—because there are many guides explaining that. (One of the best I found was Beej’s Guide to Network Programming—so check that out if you’re interested.)

(more…)