Configuring a VirtualBox VM to be shared by multiple users on the same Mac

I was asked at work to set a Fedora Linux VirtualBox virtual machine so that it could be accessed by multiple users on the same Mac. The VM had been already set up in /Users/Shared/VM_directory_name, so I reset the permissions on the VM so that it was read/write by a group that all the users were in and went off to the next issue.

Later that day, I get an update letting me know “Hey, we’re having permissions issues.” When I checked the VM, it looked like VirtualBox was giving ownership of the VM to the last user who had used the VM. Since that was locking out everyone else, this was a problem.

Fortunately, I was not the first person to run into this issue. In the event that someone else needs this, here’s one way to share a VirtualBox VM among multiple users on the same Mac.

1. Put the VM in a place that everyone can access. /Users/Shared is a good place.

2. Configure the VM to be the way you want it.

3. Go into Terminal and run the following commands:

cd ~/Library/VirtualBox

cp ~/Library/VirtualBox/VirtualBox.xml /path/to/shared/location/VirtualBox.xml

mv ~/Library/VirtualBox/VirtualBox.xml ~/Library/VirtualBox/VirtualBox.xml.bak

ln -s /path/to/shared/location/VirtualBox.xml

These commands will copy the configured VirtualBox.xml file to the shared location, back up the existing VirtualBox.xml in ~/Library/VirtualBox, and make a symbolic link to /path/to/shared/location/VirtualBox.xml in ~/Library/VirtualBox.

4. Adjust the permissions of /path/to/shared/location/VirtualBox.xml so that all of your users can read and write to this file.

Note: Because all accounts are linking to the same file, any changes to the VirtualBox configuration by one user will show up for everyone else as well. It also means that if the VirtualBox.xml configuration file stored in /path/to/shared/location is deleted or moved, it disappears for everyone.

Update 10-26-2011:

I also needed to set up a launchdaemon and script to make sure that the permissions stayed set, as VirtualBox on the Mac will reset the permissions of the VM to be exclusively owned by the account that last ran it. The permissions change happens when the VM is shutdown.

Here’s links to the script and the accompanying launchdaemon on my GitHub repo (make owner and group edits as appropriate).

Removing and rebuilding a malfunctioning Recovery HD partition

When updating to 10.7.2, there’s a Lion Recovery Update that goes along with it. This is meant to update your Recover HD recovery partition to 10.7.2 along with your Mac. However, when I tried updating, I could see from the logs that for whatever reason, my Recovery HD was staying at 10.7.1 and was not being successfully updated. As the new Find My Mac functionality in iCloud relies on Recovery HD being updated to 10.7.2, I wanted to be able to fix this problem without having to reinstall or reimage my Mac. Fortunately, thanks to the work of Clay Caviness at Google, there’s a way to rebuild your recovery partition (at least for 10.7.2) on a Mac that doesn’t have one. I did have one, but I knew how to fix that. See below the jump for the procedure.

“The Whys and Hows of Recovery HD” in MacTech’s September 2011 issue

For those interested in learning more about Recovery HD and the hidden partition it carves out of your boot drive, I have an article in MacTech‘s September 2011 issue. It’s titled The Whys and Hows of Recovery HD and is a nuts-and-bolts article that looks at Lion’s Recovery HD partition, what its purpose is, whether you need it, and methods for adding or removing it.

Creating FileVaultMaster.keychain from the command line

In FileVault 2, if you want to set a recovery key on multiple machines, you need to create and configure a FileVaultMaster keychain. Prior to 10.7.2, this was a process that you could only perform in the GUI. 10.7.2 introduces a way to create this keychain using the security command.

To create a FileVaultMaster.keychain, run the following command:

security create-filevaultmaster-keychain /path/to/FileVaultMaster.keychain



(If you want to create the FileVaultMaster keychain in its proper place, use /Library/Keychains for the destination path.)

You’ll be prompted for a password for the keychain. Use the password that you’ll be setting as your Master Password here. At this point, the keychain will contain both the private and public keys needed for FileVault recovery. Make copies of the keychain and store them in a safe place.

Once you’ve made your copies, make another copy and remove the private key from that copy of the keychain. Once the private key is removed, the FileVaultMaster.keychain is ready to be used for encrypting Macs with FileVault 2.

It doesn’t appear that the security man page has been updated with information about this new option, but you can see what it does by running security help and checking at the bottom of the list that appears.

Disabling the iCloud sign-in pop-up message

In 10.7.2, Apple set the iCloud sign-in to pop up on the first login. Since having this appear may not be desirable in all Mac environments, it makes sense to be able to turn this off for new user accounts. After doing some file tracking, Mike Boylan and Allen Golbig figured out which file controlled this. Setting com.apple.SetupAssistant.plist in /System/Library/User\ Template/Non_localized/Library/Preferences/ to include the key DidSeeCloudSetup with a Boolean value of TRUE will stop the iCloud login from automatically coming up for new users.

You can disable the iCloud sign-in from popping up with the following defaults command:

sudo defaults write /System/Library/User\ Template/Non_localized/Library/Preferences/com.apple.SetupAssistant DidSeeCloudSetup -bool TRUE

I’ve also posted this in a script available here in my GitHub repo.

FileVault 2 encryption status check script

As part of working on FileVault 2, I’ve been developing a script that can be run via various system management tools to report whether or not a particular Mac is encrypted with FileVault 2. Currently, here’s what the script is detecting and reporting:

Checks to see if the OS on the Mac is 10.7 or not.

If it is not, the following message is displayed without quotes: FileVault 2 Encryption Not Available For This Version Of Mac OS X

If the Mac is running 10.7, but not does not have any CoreStorage volumes, the following message is displayed without quotes: FileVault 2 Encryption Not Enabled

If the Mac is running 10.7 and has CoreStorage volumes, the script then checks to see if the machine is encrypted, encrypting, or decrypting.

If encrypted, the following message is displayed without quotes: FileVault 2 Encryption Complete

If encrypting, the following message is displayed without quotes: FileVault 2 Encryption Proceeding

How much has been encrypted of of the total amount of space is also displayed.

If the amount of encryption is for some reason not known, the following message is displayed without quotes: FileVault 2 Encryption Status Unknown. Please check.

If decrypting, the following message is displayed without quotes: FileVault 2 Decryption Proceeding

How much has been decrypted of of the total amount of space is also displayed

If fully decrypted, the following message is displayed without quotes: FileVault 2 Decryption Complete

The script is available here on my GitHub repository. I’ve also built a Casper-specific version for use as a Casper Extension Attribute.

Repackaging XCode 4.1 for 10.6.x

At the end of August, Apple posted XCode 4.1 for 10.6.x up on the ADC site. Since I wanted to make it available to some of our developers, I downloaded the disk image download from ADC and took a look.

Fantastic, looks like a standard installer package. So I uploaded it to my software installation portal for testing and scoped the installer so that only my test boxes can see it. The test boxes have XCode 4.0.2 on them already, so this should test upgrading as well as installing.

The package installs, I go take a look, and my XCode installations are still at 4.0.2

I run it again. Same result.

Now I run it with snapshotting on a new box, so I can see exactly what’s being installed. Nothing in /Developer……./Applications? It’s installing one thing into /Applications?

That’s right, Apple gave me a standard installer package that installs a second installer. Even more awesomely, the second installer is not an installer that I can push with my usual software deployment tools.

Fortunately, since Apple had also used the Install XCode.app route with XCode 4.1 for 10.7, I already have a fix for this issue. Use it in good health.

Disabling AirDrop from the command line

A new feature in 10.7 is AirDrop, a way to share files easily between machines that are on the same local network. Amazing-sounding as it is, there are some Mac environments where it makes sense to turn it off. See below the jump for how.