Can't delete any folder from writable volumes

[hermanc01]

Since upgrading to App Volumes 2.13.0, users are no longer able to delete any folder from their writable volume.  This includes folders before the upgrade and any newly created folder.  The user is prompted for admin permissions which even if they're supplied by an admin, they're unable to delete the folder. 

This is occurring for folders on the users' desktop as well as locations like C:\temp.

Has anyone else run into this as well?

[mhampto]

Can you check that the writable volume assignments are not in use? Are they deleting per the procedure at Delete a Writable Volume ?

[Lakshman]

Would you mind creating a new writable volume using 2.13 template and check the behavior to make sure the issue happens with older version or in the latest too.

[hermanc01]

I've double-confirmed the writable isn't in use.  The problem isn't deleting the writable volume itself, it's deleting a folder during a Horizon session while logged into the VM and the writable is attached. 

If I log into the resource without a writable volume, I am able to delete folders as expected.

I've also created a new writable volume from the template but the issue still persists.

I've upgraded to 2.13.1 and I'm still not able to delete a folder (even trying the previous steps too).

If I rollback the agent to 2.12.1, I can delete a folder as expected with the writable attached. 

[rdonohue]

We're running into this same issue? I know this is old, but did you ever find a solution. One really interesting thing is that users can delete folders from the command line without any permission prompts. When they try to delete from the gui they get the prompt that they need admin permissions. So this is clearly not an actual permissions issue.

[rdonohue]

All of our writables were created on 2.13.2.6. One additional note: this still happens if the user is a local admin. The difference is that they can hit continue, and it is then followed by a message that they need permission from themselves to delete the folder.

[rdonohue]

I wanted to check back and see if anyone has found a solution to this. Support told me that it was fixed in 2.14, but I upgraded and it is still broken.

[hermanc01]

Are you assigning drive letters to your writable volumes?  If so, start the "Shell Hardware Detection" service and try deleting a folder then. 

This was the solution provided by support for me.

[rdonohue]

Wow that works. I wish support could have told me that too! So now the only problem is that it is requiring admin permissions to delete any folders. I can do this because I'm an admin, but none of our users are. Deleting files does not require it, but deleting folders does. So weird.... Does it do the same thing for you?

[DravenX1]

We are facing this issue too after migration from 2.12 to 2.14.2.Other symptoms are explorer.exe utilization more than 25% ,long time of loading data (for example under user profile),search under start menu (cmd.exe for example) is taking long time too. Everything is good before first log off.Than we see that ,after user logs off, the writtable is detached ,but for example under user profile remains the shortcut of the useres profile (this behavior we didnt see on 2.12). After log in of user ,the user rights of only shortcut remains...

We made a ticket on vmware support,but we are 3 days without response or help,after 3 urgencies...

[Moltron83]

We are having the same issue here - where users can create a folder on their desktop, but then do not have permissions to delete it.  It can be deleted from the command prompt though.  We're running App Vols 2.18.  We recently updated from 2.17, and had applied the zip file update for the writables - thinking that may have caused the problem, I've removed the writable and recreated it on 2.18's template yet the issue persists.  Enabling the service mentioned above allows me to delete the file, but I am still prompted for admin access, and then when the service is disabled again, the issue returns.  

Anyone know what the fix could be (not workaround)?  It seems like its best practice to have that service disabled, and even with the service turned on, its still not completely right.  Users shouldn't get the admin prompt to delete a folder which they have full access to.

[Moltron83]

UPDATE:  Worked with support - once the service was turned on in the base/gold image and deployed this issue went away for good.  This service may have been disabled by OSOT - not exactly sure.  In case this comes up later somehow - the symptoms were that you could create any folder anywhere, and you could not delete it.  You could permanently delete it though (shift+del).  So more specifically the issue was with sending things to the recycle bin.