Shared folder permissions problems after Parallels 16 upgrade

A

AndreiB2

Bit poster
I have this problem after 16 upgrade. Host Mac OS Catalina, Guest Windows 10 Pro ver 2004 build 19041.450. Visual Studio 2019.
Could you advise how to fix it?
upload_2020-8-24_14-34-32.png
 
It's my problem too...
and...
after 16 upgrade..
in visual studio 2019 asp net core + entity framework
new scaffolded item is error!!!
I guess it's same problem...
 
Maria@Parallels said:
Hello, did you check this?
Click to expand...
When I tried the first suggestion, VS restarted under admin and there weren't shared folders available.
Third one, VS started under my current user but shared folder weren't available either.
Problem that some post build steps failed on external commands (xcopy, etc) with an access denied error. Particularly they can't delete folder. But if I delete it manually they will succeed.
May be in 16 version was made changes in area of shared folder possession or in area of inheritance of host (Mac) OS users's permissions?
 
I have the exact same problem. Everything was working fine and tried upgrade to 16 to get "better performance and disk management". Boy was I suckered in. Anyway I can't run VS as admin because that screws up user mappings and such needed for my application. This all worked fine before the update to 16.
 
AndreiB2 said:
When I tried the first suggestion, VS restarted under admin and there weren't shared folders available.
Third one, VS started under my current user but shared folder weren't available either.
Problem that some post build steps failed on external commands (xcopy, etc) with an access denied error. Particularly they can't delete folder. But if I delete it manually they will succeed.
May be in 16 version was made changes in area of shared folder possession or in area of inheritance of host (Mac) OS users's permissions?
Click to expand...
Are you running 15 or any previous Parallels Desktop version?
 
I downgraded to 15 since the suggested steps (uninstall/retinstall tools) to resolve this did nothing. The downgrade to 15 made it work again so I'm not upgrading to 16 at this point.
 
I have the exact same issue after upgrading to 16. All my Visual Studio projects, which I ran from a shared folder on my Mac, have permission issues. I get the 'elevated permissions' message as mentioned above but, no matter which option I choose, the project can't run any tasks because of permissions issues and 'UNC paths not supported'. Very frustrating!
 
Im seeing the same message when running VS2019 (if not run as admin) if the project/solution being opened is on a drive shared by parallels. In addition since the upgrade any attempt to use XCOPY e.g. xcopy /e / y src/* dst where both src and dst are on a drive mapped to a parallels shared folder (in my case on a removable raid array "Mac OS Extended (Journaled)") will only succeed if the destination directory is completely empty and does not contain subdirectories. If subdirs exist in the destination then XCOPY fails and outputs the messages:

Access denied
Unable to create directory dst/somesubfolderunderdst

Now looking at the XCOPY process in detail using sysinternals ProcMon you can see some interesting output which indicates that the error message being output are truly very misleading. The question is - is there a new bug in Parallels V16 (maybe 15 - not sure)? Since upgrading parallels all my automated builds stopped working correctly. Prior to the upgrade all was ok. I have checked this in a (latest) Win10 VM and also in a Win7 SP1 one. I strongly suspect a new parallels issue exists here. I would suggest to your development/testing team to try using xcopy to copy a directory tree over an existing one and repeat in regression with an earlier parallels version.

For now I have worked around the issue by using robocopy instead but something smells very bad here!
 
OK I have investigated the further. On a laptop with an older version of Parallels I created a folder structure as follows:

src
folder1
file1

(and an initially empty folder named dst)
Then

xcopy /e /y src\* dst

On the second copy attempt folder1 will already exist in dst (and due to the bug may fail if on an external drive)
I repeated this with the src and dst folders located on:

Parallels10 C: drive (under Users\MyUserName) result PASS
Parallels10 X: drive (mapped to /Users/MyUserName/Downloads) result PASS

Parallels16 C: drive (under Users\MyUserName) result PASS
Parallels16 X: drive (mapped to /Users/MyUserName/Downloads) result FAIL **

**

X:\Downloads\foo>xcopy /e /y src\* dst
Access denied
Unable to create directory - X:\Downloads\foo\dst\folder1
0 File(s) copied

The observation of this bug is clear.
Versions Tested: 10.3.0 (29227) NO ISSUES!
Versions Tested: 16.0.1 (48919) BIG PROBLEMS
The issue occurs regardless of windows version 7, 8, and 10 tested
Issue only occurs on drives mapped to Mac or to removable drives and not on the C: drive of the VM
I won't detail the procmon output which is something your devs may like to take a look at.

I'm confirming that this is a BUG in the latest versions of Parallels and will be reporting it as such.
 
Addendum to last report.
I have submitted a ticket and will await.

Regarding the cause of the issue...
It's certainly not completely straightforward but there are subtle differences in the ProcMon traces between the successful and unsuccessful runs. I'll not attempt to interpret these logs! I imagine ... This might not be an easy fix - personally I'd want to run xcopy under the debugger (with its Microsoft source code!!!).
 
Maybe not so bad. If your devs take a look and compare failing and successful Procmon logs you will see in the xcopy trace that there is a call to CreateFile (to create the copied folder in the destination|). In the successful case CreateFile simply succeeds. In the failing case we see the result IS DIRECTORY instead which seems to prompt xcopy to try 2 further (slightly different CreateFile calls) which also return IS DIRECTORY. At this point XCOPY gives up.
 
AND Here you go... the difference is...

UNDER PARALLELS 10 Result is Success

High Resolution Date & Time: 11/09/2020 16:32:01.7988249
Event Class: File System
Operation: CreateFile
Result: SUCCESS
Path: \\psf\home\Downloads\foo\dst\folder1
TID: 5148
Duration: 0.0014812
Desired Access: Read Data/List Directory, Write Data/Add File, Write EA, Read Attributes, Write Attributes, Delete, Synchronize
Disposition: OpenIf
Options: Directory, Synchronous IO Non-Alert
Attributes: D
ShareMode: None
AllocationSize: 0
OpenResult: Opened


UNDER PARALLELS 16 Result is "IS DIRECTORY" but should be "SUCCESS"
Effectively CreateFile (for an existing directory) FAILS. This is likely to impact a lot more than XCOPY!!!!
I WOULD CONSIDER THIS TO BE QUITE POSSIBLY A CRITICAL ISSUE!

High Resolution Date & Time: 11/09/2020 16:06:46.5264840
Event Class: File System
Operation: CreateFile
Result: IS DIRECTORY
Path: \\Mac\home\Downloads\foo\dst\folder1
TID: 12040
Duration: 0.0001192
Desired Access: Generic Read, Write Data/Add File, Write EA, Write Attributes, Delete, Write DAC
Disposition: OpenIf
Options: Directory, Synchronous IO Non-Alert
Attributes: D
ShareMode: None
AllocationSize: 0

Good luck!
 
I am having an issue that seems to be related. It is definitely permissions based. My virtual machine configuration is Windows 10 2004, Microsoft 365 software.
I have multiple backup Outlook .pst files that I need to open in MS Outlook (now called Microsoft 365). Before upgrading to Parallels 16 they worked perfectly but now Outlook says I do not have permissions to open the file(s). The only viable solution appears to be a downgrade to the Parallels 15 VM until a fix is deployed.

Parallel staff, any idea when this might be?
 
I have already opened a ticket with Parallels and provided a test case which only fails in Parallels Desktop 16 (fine in 15 and before). I have provided detailed tech info regarding the issue but whether or not this has reached their dev team yet is anybodies guess. Not seeming like they respond rapidly - usually 48 hours to respond to replies on the ticket and so far most of the conversation has been them asking me to do things that they could so easily just try themselves. Still we must follow their procedures no matter how pedantic they seem to be. The problem however is clearly present and very easily demonstrable. It appears that when CreateFile is used to open an existing directory (an unusual operation you might think but one which is required in order to read or write attributes and other info) it can fail when certain parameters are specified. This very much seems to be the undeniable case when it comes to xcopy failing to copy over an already existing destination directory. You can observe XCOPY making these calls using the sys internals process monitor app and see the difference between PD15 and 16. In PD16 you see XCOPY gets a failure for 2 CreateFile (opening existing directory) calls where in PD15 and earlier the same calls succeed. The destination has to be on a parallels share in order to observe the issue of course and that implies the issue probably lies in a parallels file system filter driver which is where their implementation must have changed. I have provided them with as much info as possible but I guess we just have to sit back and wait. I'm sure its not just XCopy which is affected and there are certainly indications that it affects Visual Studio and probably countless other apps. I would consider it as a critical issue. For my part I reverted to 15 (for a while) but now am limping along again with 16 having run into other issues and managing to bypass the use of xcopy in my automated builds and tests which was where I first noticed the issue as it was causing these to fail in peculiar ways.
 
Hi guys, I have similar issue with Autocad Electrical 2021. If I work on project placed on the shared drive the system return me a lot of read only issue. If I work on project placed on local virtual all work fine. The issue start after upgrade to Parallels 16 from Parallels 15.
 
You must log in or register to reply here.
Back
Top