Bootcamp initializing every time...

[mojo1733]

I am using 3188 of parallels. Every time I boot my bootcamp partition I have to autheticate twice and then it goes through the initializing Parallels tools. Is this normal? It definately drags out the bootup.

[mojo1733]

Bump. No one else has seen this.

[Al_Q]

I am using 3188 of parallels. Every time I boot my bootcamp partition I have to autheticate twice and then it goes through the initializing Parallels tools. Is this normal? It definately drags out the bootup.

I am not quite sure what you mean by authenticate twice. If you have specified that option in your Parallels preferences, you have to authenticate (in Mac OS) to start up a Parallels system. And if your PC installation specifies that you need to log in, you have to enter your Windows password after you boot Windows. Is that what you mean by authenticate twice? If it is, just change the options in Parallels preferences and Windows user accounts.

Everyone gets the Parallels Tools message while booting from a Boot Camp partition. You may have noticed that if you restart in Windows, you do not get the tools message. Then when you shut down Parallels restores the regular boot camp configuration. Booting Windows in Parallels is slower than in Boot Camp, but not a lot slower.

If you want to avoid that delay, just create a regular (not boot camp) Parallels installation. It boots faster, and you can suspend it for near-instant startup and shutdown.

[rkowal]

I'm having the same issue as mojo1733. When I start up my Boot Camp partition in Parallels, I have to authenticate twice (in the Mac OS). Similarly when I shut down, by the way (once). I cannot remember having specified this in my preferences, in fact, I can't find any place where I could turn this behavior off.

[rkowal]

P.S. Clicking on the disclosure triangle in the authentication window reveals that Parallels requests the right "system.volume.unmount".

Apparently it needs my authentication to unmount the Boot Camp volume from the desktop. How can I automate this so that it doesn't ask for it all the time?

[iwasnevy]

but it only wants me to authenticate once in OS X. The requested right is for: system.priviledge.admin

I may, however, have other keychain problems.

I'm also getting the "paralells tools initializing" message upon starting the guest OS and sluggish performance while loading the OS.

Macbook Pro 17" / 2.16Ghz / 2Gb / running Win XP on Fat32 formatted boot camp partition.

[rkowal]

iwasnevy, as Al_Q pointed out: the Parallels tools initializing message is normal behavior. But what really bugs me is the authentication every time I start Parallels in Boot Camp. (If I compare that with VMWare Fusion running the Boot Camp partition, there's no authentication necessary there...) But I really looove Parallel for its Coherence feature. So does anyone have an idea on how to get rid of authentication when using Boot Camp?

[Jowl]

I too have to authenticate when I first launch Parallels. I then get an error that it can't locate the bootcamp partition.

If I then run the VM from the configuration screen, it will work.

[intarwebs]

This is a really, really frustrating problem for me.

I am an admin in a research environment and we do not let users Administer their own Mac machines. Because of this administrative authentication required, I cannot roll out a combo Boot Camp + Parallels solution as I have to be there to mount and unmount disks.

Unfortunately, I only realized this limitation (nothing seems to be written about it) after rolling it out across four MacBooks. Now I have to revert them all to regular Parallels installs. What a hassle and a pain. I hope Parallels can address this issue soon.

[rkowal]

This is a really, really frustrating problem for me.

I am an admin in a research environment and we do not let users Administer their own Mac machines. Because of this administrative authentication required, I cannot roll out a combo Boot Camp + Parallels solution as I have to be there to mount and unmount disks.

Unfortunately, I only realized this limitation (nothing seems to be written about it) after rolling it out across four MacBooks. Now I have to revert them all to regular Parallels installs. What a hassle and a pain. I hope Parallels can address this issue soon.


I second the motion of intarwebs. But perhaps this is a problem with a simple Mac OS solution? After all, the problem seems to be that Mac OS X by default requires you to authenticate in order to unmount the partition. Perhaps something can be done by changing its permissions, etc.?

[iwasnevy]

Hi All
For what it's worth, I've solved my problem with having to authenticate each time.

I mentioned that I may have been having problems with my keychain (my gut told me that it wasn't paralells prompting the authentication each time) and that turned out to be the case. Somewhere during my archive and install of OS X, I managed to get some corruption into my keychain. I was also having problems with my dotmac account keychain syncing properly.

I had to reset my keychain (DON'T DO THIS unless you know what you're doing!) and that seems to have taken care of the authentication problem.

I'm going to try adjusting the ram in paralells to 512 to see if that improves performance. I may just get rid of bootcamp and go back to using a VM.

-Kevin

[Orkiden]

We have the same problem on all our Macs. So it means that all have corrupted keychain. But I'm not sure of that and they don't connect to .mac.
On post 4 rkowal mentioned "(If I compare that with VMWare Fusion running the Boot Camp partition, there's no authentication necessary there...)". So if this works on VMWare Fusion why not in Paralells.

I've been loking for a solution on Parallels place but this problem are not mentioned anywhere. What informaton have we got from Paralells about this?

[rkowal]

Interesting tip, I wasnevy. After resetting my keychain, I've been able to reduce authentication to once on startup, and none at shutdown. That's 66% of the problem solved.

[intarwebs]

Interesting! Unfortunately this still isn't good enough for my/enterprise situations, but it's good to hear that there is some semblance of a workaround.

Here is Parallel's official statement on the situation:

"As I know, it is impossible to mount/unmount boot camp partition w/o administrator's rights at this moment."

So it looks like this problem won't/can't be solved anytime soon...

[muzyshyn]

It is interesting that each of you say you are running Parallels in BootCamp or BootCamp in Parallels. Am I loosing something in the translation? Bootcamp is a Partition of the Mac HD where you install XP/Vista, and Parallels Desktop runs under the Mac OS. Neither would run simultaneously. I have neither of your problems. I run Vista successfully either under Parallels or under BootCamp. Please elaborate a little more on how you incorporate both.

[fs1209]

Here is Parallel's official statement on the situation:

"As I know, it is impossible to mount/unmount boot camp partition w/o administrator's rights at this moment."

I've disabled the automatic mount of the boot camp partition (via /etc/fstab), but Parallels asks two times for authentication: the first time for system.privilege.admin and the second time for system.volume.unmount.

My question is: why is Parallels Desktop unmounting something that is not mounted?

Regards,
Frank

[jcool]

Having the same problem here, and this is definitely an issue for installations that require non-admin rights.

Any chance there's a fix in 3.0?

[hachre]

If someone could find a way to stop OSX from automounting the Bootcamp partition I guess Parallels wouldn't have to unmount it each time and wouldn't need the password.

[Juggernart]

Still have to authenticate twice on startup and once on shut down of my boot camp partition with latest build 4128.
Does noone have a clue why or what could be wrong?

Thanks

[mcaramb]

Just got off the phone (after trying for a week) with pay tech support. He didn't have a solution either. Glad to see others having the same issue. It's definitely a mount/unmount permission issue with folks using a Boot Camp partition.

Why does Parallels need to unmount the partition in the first place? Can't they simply hide the drive, rather than unmount it if they are just trying to keep people from writing to it while in use?

Right now, my people are having to completely reboot in Bootcamp everytime they need to change OS's without my being here to authorize them. It really is a huge problem.

Please, someone figure out how to give system.privilege.admin, system.volume.unmount and system.volume.mount privilieges to a standard user! I can't find any info on it whatsoever.

-Mike

[mcaramb]

Okay. I know exactly what's the deal with the multiple logins we are seeing.

The first request is for system.privilege.admin. This is Parallels asking the system to let itself be run as root. Any application asking for root privileges will cause the OS to show an admin login which is why we get this first login screen.

The second request is for system.volume.unmount. This is parallels trying to unmount the Bootcamp partition, supposedly using the root permissions you just granted it. Why? I really couldn't say. To me, simply hiding the drive would be a better idea. Any mounting or unmounting of drives (even firewire externals) will cause the diskarbitrationd daemon to check credentials first. If the requesting app doesn't meet admin level creds, the diskarbitrationd dameon will kick it back to the OS and ask for admin login. What is strange is that the app should be now running as root, so it shouldn't be asking for unmount privileges at this point, but it does.

Lastly, on logging parallels off, the third request is for system.volume.mount. This is parallels trying to bring the boot camp drive back online when you exit. Again, diskarbitrationd will check credentials for this request.

So... I have found out how to give my standard users system.privilege.admin rights (somewhat involved process involving workgroup manager and editing the /etc/authorization file), which clears them for the first login window, but I can't find anywhere how to give them the system.volume.unmount and system.volume.mount privileges it still needs without full promotion to administrator group. Without being able to do this, the first solution is useless.

Does anyone know if this is possible?

Thanks

-Mike

[nvrmore100]

So... I have found out how to give my standard users system.privilege.admin rights (somewhat involved process involving workgroup manager and editing the /etc/authorization file)

Happen to have the steps for this somewhere? I have been wanting to do this for all sorts of various reasons. :cool:

[mcaramb]

Okay, I think I've got the answer to our woes... keep in mind, I know enough about this stuff just to be dangerous, so if anyone sees or experiences any problems with the following solutions, please let me know what adjustments need to be made. I realize the following solutions will compromise overall security somewhat, but nowhere near as much as giving our STANDARD USERS total administrative rights.

SOLUTION 1: This does not prompt for *any* Authorization Windows
IMPORTANT: This solution will leave your system without the ability to prompt for authorization for any app requesting root access or ability to mount/unmount drives but it will provide a "promptless" entry into Parallels.

(Workgroup Manager not needed):

1. Open Terminal. Run as root by typing sudo -s. Make sure to type in your password correctly. The prompt should now read root#

2. Make a backup of the authorization file by typing: cp /etc/authorization /etc/authorization.bak

3. Edit the authorization file by typing: pico /etc/authorization

4. Scroll down to the key marked system.privilege.admin. It should look like this:

<key>system.privilege.admin</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Used by AuthorizationExecuteWithPrivileges(...)
AuthorizationExecuteWithPrivileges is used by programs requesting
to run a tool as root (ie. some installers).
Credentials remain valid 5 minutes after they've been obtained.
An acquired credential isn't shared with other clients.
Clients running as root will be granted this right automatically.
</string>
<key>group</key>
<string>admin</string>
<key>shared</key>
<false/>
<key>timeout</key>
<integer>300</integer>
</dict>

5. Replace that entire block of text with the following:

<key>system.volume.mount</key>
<dict>
<key>class</key>
<string>allow</string>
<key>comment</key>
<string>Ability to run applications as root</string>
</dict>

<key>system.volume.mount</key>
<dict>
<key>class</key>
<string>allow</string>
<key>comment</key>
<string>Ability to mount a drive</string>
</dict>

<key>system.volume.unmount</key>
<dict>
<key>class</key>
<string>allow</string>
<key>comment</key>
<string>Ability to unmount a drive</string>
</dict>

6. Exit, saving changes. Reboot.


SOLUTION 2: Prompts for Authorization from any registered user
IMPORTANT: This is a somewhat more secure solution as authentification prompts are required from any registered user before action is taken. However, you cannot select users which do not have this authority.

(Workgroup Manager not needed):

1. Open Terminal. Run as root by typing sudo -s. Make sure to type in your password correctly. The prompt should now read root#

2. Make a backup of the authorization file by typing: cp /etc/authorization /etc/authorization.bak

3. Edit the authorization file by typing: pico /etc/authorization

4. Scroll down to the key marked system.privilege.admin. It should look like this:

<key>system.privilege.admin</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Used by AuthorizationExecuteWithPrivileges(...)
AuthorizationExecuteWithPrivileges is used by programs requesting
to run a tool as root (ie. some installers).
Credentials remain valid 5 minutes after they've been obtained.
An acquired credential isn't shared with other clients.
Clients running as root will be granted this right automatically.
</string>
<key>group</key>
<string>admin</string>
<key>shared</key>
<false/>
<key>timeout</key>
<integer>300</integer>
</dict>

5. Replace that entire block of text with the following:

<key>system.privilege.admin</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>rule</string>
<key>comment</key>
<string>Ability to run applications as root</string>
<key>rule</key>
<string>authenticate-session-owner-or-admin</string>
</dict>

<key>system.volume.mount</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>rule</string>
<key>comment</key>
<string>Ability to mount a drive</string>
<key>rule</key>
<string>authenticate-session-owner-or-admin</string>
</dict>

<key>system.volume.unmount</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>rule</string>
<key>comment</key>
<string>Ability to unmount a drive</string>
<key>rule</key>
<string>authenticate-session-owner-or-admin</string>
</dict>

6. Exit, saving changes. Reboot.


SOLUTION 3: Prompts for Authorization from specific users in a powerusers group
IMPORTANT: This is the most secure solution as authentification prompts are only accepted from users you specify in a powerusers group. The Administrators goup MUST be in this group.

(Workgroup Manager REQUIRED)

1. Install Workgroup Manager

- Download the latest set of server admin tools to get Workgroup Manager (you don't need a server to use it) at http://www.apple.com/support/downloads/serveradmintools1047.html
- Install just the ServerAdminTools.pkg located in Administration Tools->Installers->Packages
- Workgroup manager should now be located in Applications->Server

2. Setup a powerusers group in Workgroup Manager

- As you will not be connecting to a server, click Cancel on the first window you see when opening Workgroup Manager, then select View DIrectories under "Server" in the menu. Ignore any warning messages that may pop up at this point.
- Click on the lock icon in the upper right of the next screen and authorize to your directory node (for most this is the local NetInfo node, but for some this could be Active Directory) using your Administrative creds.
- Click on the GROUPS icon (middle button) in the menu on the left
- Select the "NEW GROUP" button in the menu at the top and create a group called powerusers.
- Click the "+" sign, a side window will open. Select the GROUPS icon. Drag the "Administrators" group to your powerusers group. Next, select the USERS icon. Drag your standard user account(s) into the powerusers group.
- When finished click SAVE.
- Exit out of Workgroup Manager

3. Open Terminal. Run as root by typing sudo -s. Make sure to type in your password correctly. The prompt should now read root#

4. Make a backup of the authorization file by typing: cp /etc/authorization /etc/authorization.bak

5. Edit the authorization file by typing: pico /etc/authorization

6. Scroll down to the key marked system.privilege.admin. It should look like this:

<key>system.privilege.admin</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Used by AuthorizationExecuteWithPrivileges(...)
AuthorizationExecuteWithPrivileges is used by programs requesting
to run a tool as root (ie. some installers).
Credentials remain valid 5 minutes after they've been obtained.
An acquired credential isn't shared with other clients.
Clients running as root will be granted this right automatically.
</string>
<key>group</key>
<string>admin</string>
<key>shared</key>
<false/>
<key>timeout</key>
<integer>300</integer>
</dict>

7. Replace that entire block of text with the following:

<key>system.privilege.admin</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Ability to run applications as root.</string>
<key>group</key>
<string>powerusers</string>
<key>shared</key>
<false/>
<key>timeout</key>
<integer>300</integer>
</dict>

<key>system.volume.mount</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Ability to mount a drive</string>
<key>group</key>
<string>powerusers</string>
<key>shared</key>
<false/>
</dict>

<key>system.volume.unmount</key>
<dict>
<key>allow-root</key>
<true/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Ability to unmount a drive</string>
<key>group</key>
<string>powerusers</string>
<key>shared</key>
<false/>
</dict>

8. Exit, saving changes. Reboot.


FINAL NOTES:
If somehow you've botched the authorization file to the point where it crashes your computer on reboot, you can always fix it by booting your mac in single user mode by holding down Command-S during bootup.

Then, type: /sbin/mount -uw /

Then, cp /etc/authorization.bak /etc/authorization


Hope this helps!
-Mike

[SCCHelpdesk]

I am using 3.0 build 4560
I spoke with Parallels Support and will try their answer (I will post back if successful or not):
(search the KB for) "Sharing a VM with Several User Accounts on a Mac" or click HERE (http://kb.parallels.com/entry/27/119/)

Desired Result:

Making the virtual machine accessible for several users (user accounts) on the same computer.

Required Steps:

1. Move the VM folder (located in Macintosh HD > "Your User Name" > Documents > Parallels by default) to your Mac shared folder (for example, Macintosh HD > Users > Shared).
2. In the Finder, right-click (Ctrl-click) the folder with the VM and choose Get Info from the pop-up menu.
3. In the Get Info window expand the Ownership&Permissions group.
4. Expand the Details group.
5. Set the access level for Others to Read&Write.
6. Click the Apply to the enclosed items button.

***In case of Parallels Desktop for Mac version 3.0 please do the following in addition to the steps above:

Please find the .hdd file in the virtual machine folder, right-click on the .hdd file, choose the "Show package contents" menu option, and set the access level in the "Others" field to "Read&Write" for each of the files in the package.

Now each user of your Mac is able to access the VMs stored in this folder.

[SCCHelpdesk]

well...this recommended procedure did not work. My non-admin accounts are not able to use their usernames & PW to launch Parallels. I will be back on the phone with Tech Support and see what they have to say.

[aydogdu11]

I am curious if anyone else has tried the above method and solved the password problem yet. An easier method would be a wellcome I guess, at least from my part. This procedure is too complicated for new converts to Mac like myself!

[Eru Ithildur]

Okay, I think I've got the answer to our woes... keep in mind, I know enough about this stuff just to be dangerous, so if anyone sees or experiences any problems with the following solutions, please let me know what adjustments need to be made. I realize the following solutions will compromise overall security somewhat, but nowhere near as much as giving our STANDARD USERS total administrative rights.

Hope this helps!
-Mike

Mike, on a personal note, however this may sound, I am not out to sink your boat. You did a nice job in documenting the procedure and even included a warning at the beginning. I just want to stress this so all the 'script kiddi3s' calling themselves 'l33t sysadmins' don't go around telling the Mom and Pops to set it up this way to have a 'secure way' of using the BC partition.

Well, yeah. It sure is dangerous. This can open the door to all sorts of holes for creative users... If you can do w/e the heck you want with mounting/unmounting the filesystem...

I don't call this an 'answer' to our woes, rather it is a workaround that has been entailed in theory before, but never practically applied because of the security implications.

If you feel comfortable leaving the gap open on your systems do so, but I for one would not roll this out in an enterprise environment. At home with computer illiterate kids, fine, but what happens if their 'l33t hax0r' friend finds on on-line exploit using the new permissions as a workaround?

Needless to say, if someone doesn't care about the potential holes, perfect workaround you wrote.

Maybe I am over-emphasising the risk, as anyone can pop a Boot CD in as the option between start-up volumes is open to the user if you use BC, this can do just as much damage, or more than the potential security hole. ("cd /Volumes/MacDisc" "rm -f -P *" :-/) Even OpenFirmware can be circumvented with physical access.

Anyways, "forewarned is forearmed".

[Eru Ithildur]

I am curious if anyone else has tried the above method and solved the password problem yet. An easier method would be a wellcome I guess, at least from my part. This procedure is too complicated for new converts to Mac like myself!

I don't know about too complicated for new people to Mac, more of intimidating to anyone who doesn't work with the command prompt. Which, in the case of OS X, is Terminal uses a shell (tcsh, bash, etc.).