Insufficient permission to access file

[Daaavey]

I just did a clean install of my Mac OS X (10.6.5), and installed a fresh copy of Fusion 3.1.1. Now when I try to open any of my virtual machines (that I made a copy of before I formatted the drive, and then restored into my Documents/Virtual Machines folder) I get the error message: Unable to open file "/Volumes/VMware Fusion/Virtual Dell/Virtual Dell.vmdk": Insufficient permission to access file.

Any suggestions?

[WoodyZ]

This is not a VMware Fusion issue. It is a Mac OS X User Permissions Issue.

Finder (menu bar) > Help > type "permissions" and select "If you can't open a file or folder" or select "Setting permissions".

[SvenGus]

It looks like your VM's .vmx has the full path for the .vmdk; that is, for example:

scsi0:0.fileName = "/Volumes/VMware Fusion/Virtual Dell/Virtual Dell.vmdk"

instead of simply (as it should be):

scsi0:0.fileName = "Virtual Dell.vmdk"

I had the same problem, when I restored a VM: so, I edited the .vmx (with TextEdit), as above, to solve the problem; the .vmx is inside the VM package (accessible with a right-click on the VM, and then "Show Package Contents").

[WoodyZ]

It looks like your VM's .vmx has the full path for the .vmdk; that is, for example:

scsi0:0.fileName = "/Volumes/VMware Fusion/Virtual Dell/Virtual Dell.vmdk"

instead of simply (as it should be):

scsi0:0.fileName = "Virtual Dell.vmdk"

FYI Fully Qualified Pathnames are absolutely okay providing it exists and the user has read and write permissions along the path. I have many Virtual Machines that are using FQP's without any issues whatsoever.

Also even if using the normal value for that parameter the error message will still show the FQP in the messages and it's normal and expected.

The bottom line here is the OP is using a copy made under one install of Mac OS X and copied it back to a clean build and in all likelihood used a different User Account Name then what the original Virtual Machine was copied under and hence a permissions issue which is not a VMware Fusion issue and even if it was the resolution to permission issues under Mac OS X are resolved under it, not the VMware Fusion application although in some cases VMware Fusion (the 'fusionRepairPermissionsTool') can try to resolve permissions issues however not in all cases.

In the case of you editing the .vmx configuration file and if it did have a FQP it would fail if it didn't exist or you didn't have read and write permissions along the path and in either case the resolution is independent of the VMware Fusion application and is nothing more then an End User Error.

[SvenGus]

Very interesting: I didn't know all that...

Anyway, what happened to me, I think, was that I had a virtual machine, on an external drive named "VM", and then transferred it to another drive with the same name on another computer; for some reason, thus, the path in the SCSI file name in the .vmx had become "/Volumes/VM 1/...", and I had the same error message as described before, while the permissions (inspected in the Finder) were absolutely OK.

So, it wouldn't hurt to try to simplify the SCSI (or IDE, etc.) file name in the .vmx: maybe it solves the original poster's problem, maybe not...

[WoodyZ]

I totally agree that it's worth checking and was not trying to dismiss it however as to the value of that parameter becoming anything more then the filename itself under VMware Fusion it would require the used to either manually edit the .vmx configuration file entering a FQP or having added the disk thought the Settings UI electing to share the disk and based on the information given in the OP it's more likely to be a straight forward permissions issues then a FQP issue.

[SvenGus]

Yes, now I remember: I had copied a pre-existing .vmdk, to reuse it, into a newly created VM: so, the old path must have remained.

Curiously, besides the fake permissions issue, in the VM preferences the virtual hard drive showed up, greyed out, as divided into 2 GB segments, while it definitely was not.

Thanks for all the info...

[WoodyZ]

Yes, now I remember: I had copied a pre-existing .vmdk, to reuse it, into a newly created VM: so, the old path must have remained.

If you copied a .vmdk into a new VM the .vmdk file typically does not store pathname information in it so what you're say doesn't add up.

Curiously, besides the fake permissions issue, in the VM preferences the virtual hard drive showed up, greyed out, as divided into 2 GB segments, while it definitely was not.

What to you mean by "besides the fake permissions issue" are you referring to the error message you received? If it's showing a split disk and the files are then the disk that is showing is split, it's that simple. If the disk wasn't there it wouldn't be showing!

[SvenGus]

No, it was a "regular" - not split - disk: but, well, all this seems to be more and more a mystery, also to myself (not a big deal, as it was only an experiment)...

... Ehm, to return to topic - what happened to the original poster? Did you solve your problem? Any news?

[WoodyZ]

I do not know what happened to the OP and hopfully we haven't hijacked this thread to the point its to confusing and gave up.

[LlewITPS]

Just gona post this here as someone that might search for "permissions" will come accross this post.

I had a problem with not being able to load the VM with a Win XP Pro due to the player saying that I do not have permissions set for the VM. Found another post that suggested removing the lck files. I removed the .lck folder and that seemed to fix my permissions error. Like I said not sure if this post is related to my error but might help someone else.

[lmills]

Excellent thread.  I renamed my ick folders and the VM fired right up.  Thank you. LM

[likelyja]

Hello,

I am having a similar issue but having no luck resolving it.

Can you please look at the attachment and offer me a suggestion? Thank you so much for taking the time!!!