virtualbox.org

I have just installed VB 4.0.10 on a Mac 10.6.8 that has four users. The installation works OK for the administrator but it does not work for the remaining users. When any of the non-administrator users starts the VB application, the user is prompted to create a new virtual disk in his/her account.
¿Is it possible to instal VB and that the virtual HD be accesible by all users?

Same problem here. I found many different suggestions, how to solve the problem. for example these:
http://forums.virtualbox.org/viewtopic. ... 3&p=109512
http://forums.virtualbox.org/viewtopic. ... 0&p=125376

But I did not get a working solution with these hints. And I still do not know, if it is really necessary, to set the VBOX_USER_HOME environment variable (and how to do it).

I would be very happy, if there would be an step by step-tutorial available, for using one virtual machine with all current and future-users of a Mac OS X-Host.

Thanks for help

Joerg

Hi,

I finally managed to get a working Win7 (64bit) virtual machine which is accessible by as many local non-admin users as I want.

The "Shared" folder as storage location for the virtual box container is necessary but not sufficient.

Try starting a terminal session and check the rights of the "Shared" folder by entering the following command: As you can see, the directory is readable, writable and executable by all users and groups. Besides, the "t" bit is set, which means that whoever is writing new files, the directory behaves as if the current user was the owner of it.

Now let's have a look at a typical "VirtualBox VMs" directory. Inside the subdirectory with the VM's name, you can find the .vdi file containing the virtual harddisk of the VM along with a current .vbox file and its previous .vbox-prev version.
That's the point: Whenever you start a new VM session, the .vbox file is backed up by renaming it to .vbox-prev , and a new .vbox file is created by the current session's user. But when a user creates a new file in the Shared folder, (s)he is the owner of it and the only one allowed to write to it. Other users can see and read it, but this isn't enough for VirtualBox to run properly.

What you need is to instruct OSX to grant everyone the right to write to new files in the VM directory, regardless of the original owner of the file.

OK, enough theory

Here's my step-by-step tutorial (my OSX is in German language, so please excuse my translated item names if spelled different to Apple):

1. Change the default path of new VirtualBox VMs to some directory inside "/Users/Shared".
2. Create the new VM inside the speficied shared subdirectory.
3. Create a new group in SystemSettings => Users. All users belonging to this group will have the right to write to the files/directories inside the shared VM subdirectory. I called the group "Shared". Assign users to this group.
4. Right-click on the new shared VM subdirectory in the Finder and select "Information". Open the lock by entering admin name/password. Add the new group to the list of users and rights, and assign read & write rights to it.
5. Click on the wheel pictogram at the bottom and select "Apply to all subitems...". Confirm the warning message. Close the information window.
6. Open a terminal session, switch to admin, and print the current state of the access control list entries of the shared VM subdirectory (my machine is called "traktor"):

   Code: Select all

   traktor:~ MiK$ su - admin
   Password:
   traktor:~ admin$ cd /Users/Shared
   traktor:Shared admin$ ls -eld VirtualBox\ VMs
   drwxr-xr-x+ 4 MiK  wheel  136 Jul 10 00:04 VirtualBox VMs
    0: group:shared allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
   traktor:Shared admin$ 
   

7. Copy the part after the "0: " up to the end of the line into the buffer (select with mouse, CMD-C).
8. Build up the following (complicated) command line (all into a single line, bold characters meant to be typed literally):
   • sudo chmod =a# 0 (the last character is the number zero, not a big o!)
   • a blank and a double quote: "
   • the contents of the copy buffer (CMD-V)
   • ,file_inherit,directory_inherit" (note the initial comma and the closing double quote at the end)
   • a blank
   • the name of the shared VM subdirectory.
   By doing this, you add inheritance privileges of the current read/write settings to all subdirectories and files created in the future.
   Here's my personal complete line of code given as an example (do not copy it literally!):

   Code: Select all

   traktor:Shared admin$ sudo chmod =a# 0 "group:shared allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" VirtualBox\ VMs
   Password:
   traktor:Shared admin$
   

9. Exit the terminal session, and reopen the information window for the shared VM subdirectory. Open the admin lock, click on the wheel below the users/rights list and select "Apply to all subitems..." entry again. Confirm the warning message, and close the information window afterwards.

Congratulations, you're done!

Now the additional inheritance rights are active for all current and future files inside the shared VM subdirectory. These rights allow every member of the new group to read and write all subdirectories and files of the shared VM subdir. No more hassle with VirtualBox complaining that a file is inaccessible!

The inheritance ACL rights are not shown by the finder, they can be set only by shell commands. That's why you need the "chmod" command line.

I hope it works for you as flawlessly as it does for me.

Greetings,
MiK

Dear MiK,

thank you very much for your great help and all the explanations. Now it is working for me

Joerg

Thank you MiK, but, as far as I understand, your method implies to create a new VM in the Shared folder. It is not clear whether or not all non-admin users will have access to the virtual disk previously created in the admin-user folder (if possible, I don't want to install Windows and all programs agin). It is not possible to replace the new virtual disk of the Shared folder with the old one of the admin folder (an error occurs: the ID of the old machine does not match the ID contained in the Library folder).

Hi jac,

sorry for being late with my answer, but I had to experiment a bit to find a solution for you. Eventually, I got it!

You're right, the virtual machine is not happy when it discovers that you have exchanged the VDI file. It stores all administrative information in the .vbox file in XML format, and each virtual harddisk gets a unique ID. This helps VirtualBox to keep track of the Virtual Machines (VMs) accessing various virtual harddisks on different real harddisks / file systems ...

I had an old WinXP Professional installation called "Stall" in my private Library folder ("/Users/MiK/Library/VirtualBox/Machines/Stall"), which I wanted to migrate into a shared-access VM. I assume that you created your non-admin local VM with a pre-4.0 version of VirtualBox, as I did with "Stall".
If this is not the case, the transfer might be easy (not tested, though): Just detach the VM from the left navigation pane in the VirtualBox Manager by right-clicking on it and selecting "Remove" (do not delete the data assigned with it!), move the complete directory from the original location into the shared folder using the Finder, and proceed with re-assigning the VM at its new place using the VirtualBox Manager (Menu "Machine" => "Add" (not "New"!), select .vbox file at new location).

On the other hand, pre-4.0 installations are somehow special: They store the VM information (.vbox) and the image file (.vdi) inside discrete directories, and the image is under constant supervision of the VirtualBox component "Virtual Media Manager".

Here is the step-by-step guide for moving such an installation to a shared location:

1. Make a backup, e.g. TimeMachine. Things may go wrong, and once your VM is corrupt, it might reach a state beyond repair
2. Release the assignment between the VM and the VDI file: In VirtualBox Manager, click on "Change" for your VM, jump to the "Storage" tab at the top list, activate the .vdi entry in the mass storage list and click on the harddisk symbol with the red "minus" sign below the list. Don't worry, it won't be deleted, you can re-assign it at any time. Click on OK to confirm.
3. Switch to the "Snapshots" view for your VM. There you should delete all existing snapshots.
   Snapshots are implemented as "differencing images", i.e. addititonal VDI files which store the changes meant to be stored in the original VDI file since you created the snapshot. Instead, the original VDI file is left untouched, and the new VDI file is used instead. But these differencing images multiply our workload for the transfer, and chances are high that the VM will complain about non-existent VDI files afterwards.
   By deleting the snapshots, their underlying VDI files are merged with their parent one. This is a time-consuming process. Stay calm until all snapshots are gone and the "Current State" is the only entry left.
4. Open the Virtual Media Manager (Menu "File" => "Virtual Media Manager"). There you can see all registered media files. If you had made snapshots once before, you'll see a triangle left to the .vdi file. Click it to open the snapshot hiearchy.
5. Remove all the snapshot .vdi files from the downmost child one up to the root VDI file. Do NOT remove the files physically, but just confirm that you want to remove it from the list of known media. Close the "Virtual Media Manager" window when done, and shut down the VirtualBox Manager completely.
6. Create a new directory called "Virtual VMs" in the "/Users/Shared" area. Move the complete VM subdirectory called like your VM into this new directory using the Finder ("/Users/MiK/Library/VirtualBox/Machines/Stall" => "/Users/Shared/Virtual VMs/Stall" in my case). Move the VDI file from the adjacent "Harddisks" subdirectory directly into the new VM subdirectory ("/Users/MiK/Library/VirtualBox/Harddisks/Stall.vdi" => "/Users/Shared/Virtual VMs/Stall/Stall.vdi" in my case).
7. Now you can proceed to my previous description regarding the creation of a shared VM accessible by all non-admin users which are member of a special group. Of course, you need not create the new machine, as the new VM subdirectory is already in place and waiting to be reconfigured. Create the "Shared" group, do the "chmod" call, and populate the new rights to all items and subdirs inside the "/Users/Shared/Virtual VMs" directory using the "Information" window features, as described in my post above.
8. It's too early to add the VM to the VirtualBox Manager again: We first have to register the VDI file at its new location. Open the VirtualBox Manager again and there the "Virtual Media Manager".+
   But hey, there's no "ADD" button for a new virtual harddisk!
   I really don't know why it's missing, but you can simply drag 'n' drop the VDI file from the Finder window into the (empty) list of virtual media harddisks. The mouse pointer will change to an alias arrow, and the VDI file will be smoothly added.
9. Now that the VDI file has been registered, you can add the VM again: Close the "Virtual Media Manager" window and switch back to the main VirtualBox Manager window. Select "Machine" => "Add" (not "New"!) from the menu, and select the .vbox file at its new place ("/Users/Shared/VirtualVMs/Stall/Stall.vbox" in my case). Hold your breath
   If nothing did go wrong in between, the VM should be listed again in the left pane.
10. Click "Change" and proceed to the "Storage" tab. Re-assign the VDI file to the corresponding controller by clicking the harddisk "plus" sign for it. Choose "Select existing disk", and select the newly stored VDI file.

Puh, that was nerve-stretching

Fasten your seat belts, start your engine, and hit the pedal to the metal

If anything goes wrong, do not hesitate to leave a note here. I'll do my very best, but by all means, keep your backup safe!

Greetings,
MiK

Dear MiK,

Thank you for the instructions. This also works for network groups. I just set the group ownership of the VM directory in Shared to both admin and lab (our network group).

Brian