Not sure you can do this directly.
In theory, when you run utility XYZ that interacts with the file system in a domain-based or workgroup-based environment, your ability to do so depends on the way Windows identifies you to the file system. Your permissions are maximized against any access control entries (group identifiers) and permissions associated with the file AND any group identifiers associated with your account. Once that permission maximization occurs (inside the access arbitration manager), the system knows what you can do - and what you can't do.
The catch is that I'm not personally aware of a way to install a product with extra privileges or group identifiers that would "bleed through" to your session. That doesn't mean you can't, only that it is not obvious how to do that.
If you cannot install an image with extra group identifiers that participate in the session's group membership, then your apps (such as Access) run with the same permissions as any other app. And vice versa. So if Access could delete it, the DELETE program could do just as well - because they have the same user context.
Try a web search for "Windows Images with extra Group Identifiers" (and variant phrases like that) because that is the only way I know to make it work for a Joe Average User account to do something with one utility that they couldn't do with another.
Outside of that, I would say try this:
Make a list of files to be MARKED for delete - but don't delete them yet. If a file is to be deleted, add it to a table or mark the record where it is referenced or something much like that.
Search this forum if you don't already know how to do this on how to schedule a Windows Task Scheduler run of Access using the -x option to specify a macro name. Or if you don't want it automated, make it a macro that you can run. Have the macro run code that deletes files from the "Marked for delete" list. If the macro is run from the task scheduler, remember to include a QUIT step at the end of the macro. In that case, run the item as SYSTEM or at least as a username that has sufficient rights to do what you wanted to do. If you need a password to get into that username, I'm not sure how to handle that, but the forum may have some options there, too. Is there a way to specify a username and password from the command line? Look up Access command line options in the help files to answer that question.
To make it spiffier, use this approach: Add a flag in whatever record holds the original file reference, "MrkDel" or something similar, saying "This file is marked for delete" - then fix other queries that reference the files to disallow use of marked records. So it looks like the record was deleted with the file, but it is still there. Just not responding. If the user tried to see the file directly, OK, it would still be there, but Access wouldn't touch it if you marked it appropriately.
Now, your problem is simply to run your macro or code from an account that has delete access to the folder, but general users can only have create access to the folder. Which means it cannot be the folder where the database resides because of permissions needed on that folder.
By using "Mark for Delete" plus deferred deletion, you can have closer control over what is done and when it is done, including logging and such. Which is surely a good thing.
