Ooh, now mine is doing the same behavior. Maybe it always did and I just didn't notice it (I think it just started prompting me?)
1 person found this helpful
Answer is still no. The problem is not permissions on the file, it's that we need to allow the guest to directly read and write to the disk. Normal programs aren't allowed to do this (or else they could trivially corrupt your disk), so Fusion needs admin privileges.
When you say "Fusion needs admin privileges", does that mean that only a Standard Mac OS X user account would see this message? 'Cause the accounts Fusion is launched from are both currently Admin accounts...
I believe even an admin account will see the prompt. Just because you're an admin user doesn't mean you don't have to enter your password.
Well, if it's supposed to do that, I'll accept it. It is, however, an odd thing that most users wouldn't expect. Thanks for the info.
A number of posts regarding this topic want a solution to be able to power on/off VMs within VMWare Fusion as a Standard User (i.e. non-administrator) without:
1. Providing users with the credentials of an administrative account
2. Opening up a major security hole in OS X by granting all users system.privilege.admin (by modifying /etc/authorization, e.g.).
A typical scenario would be a laboratory/classroom of Macs where users/students require access to a VM. The provided command line utility vmrun cannot be used because it will invoke a non-privileged instance of VMWare Fusion.app (which will later prompt for administrative credentials).
The solution is use sudo with appropriate ACLs so that a Standard user can (only) invoke - without a password - a privileged (i.e. root) instance of VMWare Fusion.app. This process will then have system.privilege.admin rights (along with system.volume.mount and system.volume.unmount) and the prompts for administrative rights will not occur.
1. The sudoers file is modified so that only the shell script which invokes "VMWare Fusion.app" can be run as any User. (In particular, other commands on the system cannot be directly executed as root.)
2. The Standard user will have full/root control over VMWare Fusion (i.e. they will be able to create/modify/delete VMs etc). There is an inherent security risk to this. In particular, anything that "VMWare Fusion.app" can do as root, your standard users will be able to do (by proxy). However, IMHO, it is much better than providing users with the credentials of an admin account or modifying /etc/authorization (as described above).
Please be aware of the above and test it within your environment prior to deployment.
The steps required are as follows:
1. Create a shell script at /var/root/powerOnVM.sh (e.g) with the contents:
/Applications/VMware\ Fusion.app/Contents/MacOS/vmware /path/to/vmxFile.vmx 1>/dev/null 2>&1 &
(in my case the path to the VMX file was /Users/administrator/Library/Application\ Support/VMware\ Fusion/Virtual\ Machines/Boot\ Camp/%2Fdev%2Fdisk0/Boot\ Camp\ partition.vmwarevm/Boot\ Camp\ partition.vmx)
Make the shell script executable as follows:
chmod +x /var/root/powerOnVM.sh
2. Edit /etc/sudoers (using visudo) and add the following line beneath the "Cmnd alias specification"
Cmnd_Alias POWER_ON_VM = /var/root/powerOnVM.sh
3. Beneath the "User privilege specification" section (in /etc/sudoers) add the following:
%staff ALL=(ALL) NOPASSWD: POWER_ON_VM
This allows all members of the UNIX group "staff" to be able to invoke /var/root/powerOnVM.sh as a standard user. (Note: All users on OS X by default are members of the staff group AFAIK. Group membership can be queried using 'id' from a bash terminal.)
4. A Standard user should now be able to execute "sudo /var/root/powerOnVM.sh" from a terminal. An instance of "VMWare Fusion.app" as root should be created
5. Having users drop to a terminal isn't particularly elegant. Open up Script Editor and create the following Apple Script:
do shell script "sudo /var/root/powerOnVM.sh"
save as an Application, set to run and deselect "Startup Screen"