+- Antwise community forums (https://forums.antwise.com)
+-- Forum: Vimalin (https://forums.antwise.com/forumdisplay.php?fid=4)
+--- Forum: Vimalin for VMware Fusion (https://forums.antwise.com/forumdisplay.php?fid=8)
+--- Thread: restore permissions (/showthread.php?tid=131)
restore permissions - kgp06 - 2022-08-18
I have a successful Vimalin backup of a Fusion vm, and have successfully restored it. I renamed the .vmwarevm file back to the original name from the "backup" name that was restored. It was restored to the same folder that the original was located.
When Fusion tries to start the virtual machine, it says it cannot find "Virtual Disk.vmdk", but when I hit the Browse button, that file is in the list of displayed file names. Choosing it there, the next thing is "Error while replacing a missing file: Insufficient permission to access the file."
I'm not sure if the renaming is the source of this problem or if there are some missing macOS permissions? I did give "full Disk Access" to the Vimalin app and the VimalinWorker process. The backup and restore operations in Vimalin do not show any error in the logs. But the net effect is the restored virtual guest will not start. Thanks in advance for any suggestion.
Vimalin ver 2.6.560
Fusion ver 12.2.4
macOS ver 12.5
RE: restore permissions - wila - 2022-08-18
Hi,
That's peculiar.
Can you try the following.
With VMware Fusion closed.
Right click on the VM -> Get Info -> set file permissions for your user name to "read/write".
If already on "read/write" then change it to something else, close the panel, open it again and change it back to "read/write".
Do you still have the same issue?
Nevertheless I still want to see the following two things from you.
1) the support bundle from Vimalin. You can create that from the help menu -> option "Create Support bundle"
2) all the vmware.log files in the VM's bundle (right click -> Show Package contents), grab all the vmware.log files.
Compress the log files and then send them along with the support bundle by email to support@vimalin.com
Thanks
--
Wil
RE: restore permissions - kgp06 - 2022-08-18
(2022-08-18, 08:41:13)wila Wrote: Hi,
That's peculiar.
Can you try the following.
With VMware Fusion closed.
Right click on the VM -> Get Info -> set file permissions for your user name to "read/write".
If already on "read/write" then change it to something else, close the panel, open it again and change it back to "read/write".
Do you still have the same issue?
Nevertheless I still want to see the following two things from you.
1) the support bundle from Vimalin. You can create that from the help menu -> option "Create Support bundle"
2) all the vmware.log files in the VM's bundle (right click -> Show Package contents), grab all the vmware.log files.
Compress the log files and then send them along with the support bundle by email to support@vimalin.com
Thanks
--
Wil
With Fusion closed I changed the .vmwarevm bundle permission to read only. Applied the change, closed the dialog, and then changed it back to read/write. This did not change the outcome, starting the guest still raises the same Fusion error about the file permissions.
The support and log files are on the way to the email address you supplied. Please advise if you see something else to try.
RE: restore permissions - wila - 2022-08-19
This turned out to be a permission issue.
The restore process is not setting the ownership on the files back correctly, instead the ownership was set to root:wheel for the user.
We are investigating and will release a fix.
Meanwhile you can resolve this by issueing the following command:
Code:
sudo chown -Rf <user>:<group> /path/to/vmware/bundlewhere <user>:<group> is something along the lines of
Code:
wil:staff(You can check that for /path/to/vmware/bundle as it does set the ownership correct for the bundle folder itself, just not for the files in the bundle)
--
Wil
RE: restore permissions - wila - 2022-10-19
Couldn't reproduce this for a while.
Turns out that the way to reproduce this was to first compress the VM.
On Decompressing, the ownership of the files has changed to root.
Then on restoring the ownership was retained.
Not the best choice. This was just fixed in version 2.6.587.
Now on restore the ownership of each file will be reset to the current user.
This would also resolve an issue if you import a backup and user just happens to be set to a different user.
--
Wil