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:
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.
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.
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.
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.
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.
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.
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
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.