"Multiple Errors: DoPhysicalFiles - Access to the path is denied. " when deleting files. What permission shall I use?

Some update. I compared the used folder permission of orphaned and non-orphaned files and discovered something strange.

All regular files that are still in use contain permission for "Aras Vault AppPool .NET Core".

But most (not all...) orphaned files doesn´t contain this permission anymore. Instead they contain a permission for a local user account. When I add the Vault AppPool permission manually, I am able to delete the file.

Which setting can lead to this "change of permission"? I assume it´s an IIS setting, but I am not sure.

Hi community,

after an eternity I finally build a PowerScript to repair the wrong permissions. 

The issue itself was trivial and caused by moving the Vault Server to a new Server instance. For previous files, the permissions weren´t set correctly and only new files used the correct Vault AppPool permission.

So the permissions are correct now I can can cleanup the orphaned files. But I run into a new problem. Some years ago we had a few minor stability problems with the server, so in rare cases file uploads failed. I can literally tell the 3 days in 2019 where File Upload didn´t work as expected. In this case, users simple reuploaded the files and everything was fine.

But the previous invalid file uploads now lead to problems when I want to cleanup this orphaned files automatically. The files appear in the "Files" database table, but do not physically exist in the file vault. When I want to remove the files, I get an "DoPhysicalFiles [..] (500) Internal Server Error" error message. 

A possible fix is to rebuild the missing Vault folder with a fake file. But doing this for a unknown amount of files (I expect 50..) is a bit painful when doing it manually.

Does anyone know a simple way to check, if a file listed in the "File" database  exists physically in the File Vault? I know that previous users have build something like this already and I would be happy if I don´t have to start from the scratch :D

Thanks for any help!

Angela

Solved it! I used the fake file approach. There were a lot more files affected. Issues was caused by Innovator 12 update in 2019. I guess a wrong IIS setting was the root cause. It´s not an issue in newer Aras versions. My file Vault is now clean and only contains valid files with correct permission.

Here is a possible repair solution for adventurous admins that will definitely make Aras support cry:

• Rebuild the missing folders with fake text files (Innovator only cares for the folder ids, not for the file inside). Fake files are important, without them later cleanup it will not work!
• Add VaultApp permission to affected folders with Powerscript.
• Now finally delete the corrupted orphaned files in Innovator
• Et voilà – nobody will notice that anything shady ever happened. 

Of course try with single files first, cause a lot of things can go wrong. Make a backup of everything before doing these kind of operations!

I love that the software actually allows me to do stuff like this! Very much appreciated!