virtualbox.org

I just realized that the last line in my last post may have made it sound as if I was implying this problem had been solved, or maybe the implication was not noticed, but just to be clear, the problem does still persist at this point.

vboxmember wrote:Simplified example: user1 creates a VM called tempVM1, and user2 creates a VM called tempVM2
tempVM1.vdi, and tempVM2.vdi are both ending up in /media/ic3_1/.VirtualBox/HardDisks/
but, tempVM1.xml is ending up in /media/ic3_1/.VirtualBox/Machines/tempVM1/
and, tempVM2.xml is ending up in /media/ic3_1/.VirtualBox/Machines/tempVM2/

I hope this clarifies the error I made in the previous post.
Thanks again for taking the time to help me figure this out.

This is correct behaviour, VDI's may be located in 1 central repository(folder), machine XML definitions should also be in 1 central repository BUT must be identified by folder names per machine.

The point that does not seem to work for you is the location of the master virtualbox.xml file, however your example looks like both users are using 1 and the same virtualbox.xml file given your test examples, which is correct as well. So the question remains, whats the problem at the moment?

The problem at the moment:

This is what VirtualBox looks like when you start it from user1's account:


This is what VirtualBox looks like when you start if from user2's account:


Notice how the virtual machine in user1's account does not show up in user2's account?
Thats the problem.

Then user1 and user2 are using 2 different master virtualbox.xml files, its as simple as that, create a new vm with user2 and do a search for the master file, there should be two of them, VBOX_USER_HOME is not working as it should.

ok, I think I am beginning to see where I was confused. When you mentioned the "master" xml file I thought you were referring to the xml file that gets created in the Machines directory named after the VM that got chosen when the VM was created. I think I'm beginning to understand the bigger picture here, that the environment variable VBOX_USER_HOME is somehow not telling the OS where to correctly find a single master xml file for all user accounts called "VirtualBox.xml". Is this correct?

I did a comprehensive case insensitive search as root of every folder and subfolder on every hard drive for "virtualbox.xml" and came up with the following instances of the file.
File: [VirtualBox.xml] Size of file: [1,891] Folder: [/home/user2/.VirtualBox/]
File: [VirtualBox.xml] Size of file: [2,844] Folder: [/home/user1/.VirtualBox/]
File: [VirtualBox.xml] Size of file: [1.203] Folder: [/media/ic3_1/.VirtualBox/]
File: [VirtualBox.xml] Size of file: [1,658] Folder: [/media/ic3_1/.VirtualBox/Machines]

So... this makes me wonder why VBOX_USER_HOME is not referencing /media/ic3_1/.Virtualbox/ like it reports that it is on all accounts of .bashrc and "export -p".
Got any clues as to what to do about this from here?

I guess I could attempt to rename and move all the master xml files that are not supposed to be used someplace out of view of the OS, but I'll wait to see what you have to say about this first.

vboxmember wrote: Got any clues as to what to do about this from here?

Rename them, see if they get created again.

[UPDATE]

Ok, so I moved the "/home/username/.VirtualBox" folder for both user1 and user2 (where "username" is the name of the respective users account) off the computer onto a storage disk.

When starting VirtualBox from the user1 account, it started as if it was starting for the first time and recreated the .VirtualBox directory in the "/home/user1/" account folder. It also reset the links to the Default HardDisks and Machine folders in the preferences option under the file menu to point to the recreated "/home/user1/.VirtualBox" folder.

This tells me that VirtualBox 'might' be hard-coded someplace to look in the user1 home directory for its startup files.
Is there a way to stop VirtualBox from behaving this way and to force it to use the directories I've set for it on "/media/ic3_1/.VirtualBox"?

Yep thats what VBOX_USER_HOME is for.

I haven't tried the symlink example you gave because I don't have anything to symlink too (or maybe from depending on what you mean). There is only the one xml file in use.

For what I have, this this:
I have ~/.VirtualBox/VirtualBox.xml. That is a symlink to /media/extern/Virtual Machines/VirtualBox.xml. So each user symlinks to one and the same file. You need that file to be the same for both users, else they won't see the changes that are made when a VM is created or removed, or a file is added to the Disk Manager.

Setting the variable is that makes this unneeded, but as I'm not always sure if the variable is picked up, I rather use a method which I'm sure works. It may not be the best solution, but it gives me what I want.

So basically, what were finding out here, is that the environment variable method for solving this problem doesn't work?
Maybe there's some other place (other than .bashrc) that the OS checks to find where to look for VBOX_USER_HOME. Maybe in /etc/profile or something like that? I'll have to check, but where the OS looks for environment variables might have been changed in Ubuntu hardy haron v.8.04. It is really freaking strange that the environment variable isn't working even when all sings point to the fact that it should be.

As far as the symlink method goes. Do I want to link the actual ~/.VirtualBox/VirtualBox.xml file with the one on the ic3_1 drive or delete it and create an empty file container called VirtualBox.xml that is a link to the one at /media/ic3_1/.VirtualBox/VirtualBox.xml? If I'm not deleting it, will it matter that the two files have different sizes and have different time stamps?

Thanks for giving me some idea's for things I could try out. I'll let you know what happens.

Fwiw, under windows you can change HOMEPATH and APPDATA and then fireup VBox to do more or less the same as a linux symlink.

Symlinking involves replacing the file with a link to a file. So you remove the ~/.VirtualBox/VirtualBox.xml file and link it to your shared file. Just like I have with mine. I made mine with this command, modify it for your own situation. That '\' is needed to escape the space. You can also enclose the whole path with quotes, but using tab completion is a lot easier. Tab completion will add the '\' automatically. All you have to do after that, is check the link using ls -l. It should give a line like this: Edit:
I did some searching for the variables. It seems that you need to set them to your ~/.profile file. If you want to make it system wide, so all new users will have it too, set it to /etc/profile.

[UPDATE]
Adding the environment variable to the "/etc/environment" file (apparently this is a special system wide environment file) didn't seem to change anything. I added the following line on a line by itself at the end of the file:
VBOX_USER_HOME=/media/ic3_1/.VirtualBox/

Creating the symlink caused a file permission error, because for whatever reason symlinks are forced as root owner and group and once that link is created it won't allow me to change those permissions even if I'm logged in as root.
If I attempt to create the link logged in as user1, then the link still gets made with "root" user and group permissions applied with no way to change them. Meaning once there changed there automatically and immediately changed back to root permissions.

Here is a copy of the error message received when I attempt to start VirtualBox:
---------------------------------- Error Message Begins ----------------------------------
Failed to create the VirtualBox COM object.
The application will now terminate.
Could not lock the settings file '/home/user1/.VirtualBox/VirtualBox.xml' (VERR_ACCESS_DENIED).
Details:
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
VirtualBox
Interface:
IVirtualBox {779264f4-65ed-48ed-be39-518ca549e296}
---------------------------------- Error Message Ends ----------------------------------

Is there a way to create links that don't have root permissions forced on them?
The command I used was as follows from the ~/.VirtualBox/ directories after removing the ./VirtualBox.xml files:
Note: This command was attempted once as root. The link was erased, and it was tried once again as user1 both with the same results.
ln -s /media/ic3_1/.VirtualBox/VirtualBox.xml ./VirtualBox.xml

ls -al shows the link as being "from" ~/.VirtualBox/VirtualBox.xml "to" /media/ic3_1/.VirtualBox/VirtualBox.xml
On the link file, both owner and group are listed as root. Any attempt at chmod or changing the permissions in the GUI results in no error messages, and also no changes in the permissions.

I feel as though I'm reaching another point where I'm out of options. Any suggestions?

[UPDATE]
I've also added the environment variable to the file /etc/profile
Also, here is the output from ls -al VirtualBox.xml
lrwxrwxrwx 1 user1 user1 39 2009-04-26 14:10 VirtualBox.xml -> /media/ic3_1/.VirtualBox/VirtualBox.xml

Note: that even though it shows user1 as the principle owner and group from the CLI, all GUI interfaces to the file system show "root" as the principle owner and group for this file. Also note that the error message is complaining about "VERR_ACCESS_DENIED", so I'm inclined to think that the GUI might have it correct. This is further confirmed by the fact that "sudo VirtualBox" will start the program as if its been started for the first time (without the startup ACCESS_DENIED error) but with the same problems still persisting. Meaning no VM's are listed once it starts.

So, maybe I'll try deleting the links, and restarting the computer to see if VirtualBox somehow picks up the newly added environment variables from /etc/environment and /etc/profile.

[UPDATE]

I've deleted the ~/.VirtualBox/ folders and there contents from both user accounts. Sometimes when you get tired you forget to do simple things like reboot the computer or log out and back in after adding system wide environment variables.

So, it was either, /etc/profile or /etc/environment that let the OS pick up the environment variables added. I will test this by deleting it from one of them and restarting the computer, but for now here is the current results.
When I first started VirtualBox it was complaining that user1 did not have access, but this time it was pointing to /media/ic3_1/.VirtualBox/VirtualBox.xml instead of /homes/user1/.VirtualBox/VirtualBox.xml. So this was a huge improvement because it meant the OS had found the environment variable VBOX_USER_HOME and was using it. To address the access error I rechecked the /media/ic3_1/.VirtualBox/ directory and some of those files had gotten "root" permissions established, so I changed them back to user1 as the principle owner, and vboxusers as the group. This solved the ACCESS error, but the VM was now not showing up at all, so I used the trick I discovered where you delete the xml file in the Machines folder and use the vdi file you've already created when you build a new VM. This did the trick and I was able to get the VM to show up in user1's account.

Long story short, the VM is now showing up in user2's account, but there is an access problem. Here is a picture of VirtualBox from user2's account:


This is by far the closest I/we've gotten to getting this to work so far, so this is really good news!
Ok, I've just checked the file permissions on the xml file in the machines folder, and when the VM was created VirtualBox assigned owner and group to user1, I changed the group to user2. I'm now going to login to user2's account to see if that did the trick...

YES! This problem is finally solved!!!!

RECAP: (For any one who might be searching this thread for an answer to there problems)
For, Kubuntu Hardy Haron v.8.04, the file /etc/profile and or /etc/environment need to contain the line:
VBOX_USER_HOME=/your_chosen_directory/.VirtualBox
Where "your_chosen_directory" is the directory where you've chosen to share VirtualBox between user accounts.
Make sure you remember to reboot or restart your session so that the OS gets a chance to find the system wide environment variables.
After this, check and recheck all the files and folders inside and including the /.VirtualBox/ folder to make sure that the file permissions have "vboxusers" set as the group the files belong to. Also make sure any user who will be using the same VM is a member of the vboxusers group (as is stated in the VirtualBox Manual).

A BIG HUGE THANKS for vbox4me2, and sasquatch for being immensely patient with me. Thank you both so much. Thanks.
Note: No symlinks necessary.