I have a few Mac OS X systems, in particular a MacBookPro that my job gave me. 2.33 GHZ w/ 2GB of memory Core2Duo. It's a fine and dandy machine and I'm real happy with the performance of VirtualBox on this system. Since my job is really about facilitating running Java on open source OS's like Ubuntu what I need is for a virtualized OS to feel very responsive. But I also need to compile OpenJDK source on that OS.
I didn't want to configure the virtual Ubuntu to have a large disk. By default when VirtualBox creates a virtual disk it's an 8gb disk image whose size grows as needed. This size is perfectly adequate to install an OS like Ubuntu along with some applications. Indeed my virtual system right now is using only 4GB. But an OpenJDK build takes lots of disk space.. so.. what to do?
One option would be to use a network file sharing protocol (NFS, Samba, or AFP) to export file systems from the Mac. Ubuntu is able to connect to at least NFS and Samba (not sure about AFP) .. but one issue with this is the System Preferences for Sharing on OS X a) does nothing to configure NFS exports, b) prefers AFP, and c) cannot limit sharing to within the computer and instead assumes sharing is going to be over the Internet. Okay, sure, sharing usually means, about 99% of the time, sharing between physical computers. But I can't be the first one to want to share files between virtual machines inside one single computer.
However VirtualBox has a Shared Folders feature. Support for this is part of the Guest Additions and it only runs on Linux and Windows host OS's (at the moment).
First you declare some shared folders. Click on the Devices menu and you'll see Shared Folders
Up pops a dialog box that lets you configure the shared folders. It's a simple list and there are two important values: the share name, and the host filesystem path to share. The host filesystem path is the directory on the host computer to share.
Once you declare some shared folders comes the second step, mounting them inside Ubuntu. Consult the VirtualBox users guide, section 4.5, Folder Sharing. Since the Guest OS is a Linux variant you want the second part of this manual section. The command in question is:-
mount -t vboxsf [-o OPTIONS] sharename mountpoint
The sharename is the name chosen above. For example I've shared the Mac directory /Users/dherron/jdk6-open with the sharename of jdk6-open-share. The mountpoint is the directory within the guest system to mount this share. For example:-
$ sudo mount -t vboxsf jdk6-open-share /home/dherron/jdk6-open
This command is executed as root, note the 'sudo' prefix. If I try this without 'sudo' the mount fails saying that only 'root' can do this. In the Ubuntu Authorizations application there is a choice that appears to give permissions to regular users to perform mount commands, but this didn't seem to allow me to mount a filesystem.
Running this command by hand has a couple problems. One is it doesn't do the mount every time the virtual system is booted. That may be what you want, but I want to have the mount active all the time. Second once the mount is active the files are owned by root and are read-only to my virtual user ID.
It turns out to be relatively simple to add an entry to /etc/fstab to invoke this same mount
jdk6-open-share /home/dherron/jdk6-open vboxsf defaults,uid=1000,gid=1000 0 0
Now when the system is booted this will mount automatically.
The uid=1000,gid=1000 is one way to fix the issue of root owning the files. The VirtualBox manual has this cryptic thing to say:-
Especially useful are the options uid, gid and mode, as they allow access by normal users (in read/write mode, depending on the settings) even if root has mounted the filesystem.
What this means is in the mount options you specify uid=NNN and gid=NNN and the mounted files will be owned with those UID/GID values.
UPDATE:
I wrote the above before actually doing a reboot. Well, I've since rebooted the virtual system and the mounts did not automatically mount on bootup. Sooo... Once booting the virtual system execute this command:
$ sudo mount -a
Another issue is executing files on the shared folder. Remember I'm using this to compile OpenJDK sources, and there are a lot of executable files being built and run throughout the execution. The build failed in a weird way and this turned out to be the problem.
The cure was to add exec to the options in /etc/fstab.