VBA Error 70 Permission Denied: Macros Blocked From Files, Folders and Ports

Fix it now

Error 70 is “Permission denied”: Windows refused the macro’s request to touch a file, folder or device. VBA is not blocking you and Office is not blocking you. Something between the macro and the file system is – an attribute, a handle, a permission, or a security product.

1. Click Debug, read the failing line, and note the exact path it is working with. Print the path first if it is built from variables.
2. Do the same thing by hand: create a text file in that folder in Explorer, under the same account. If that fails, the macro is innocent and the destination is the problem.
3. Check the target file’s properties: clear Read-only, and tick Unblock if that checkbox is offered on the General tab.
4. Close every Office application and look in Task Manager for a leftover host process still holding the file open. Failed automation runs leave these behind constantly.
5. If the write goes to Documents, Pictures, Videos, Music or Favorites, check controlled folder access: open Windows Security, Virus & threat protection, then under Ransomware protection choose Manage ransomware protection.
6. Retry against a plain local working folder. Success there proves the destination is at fault rather than the code.

Read the security product’s own log or protection history before you exclude anything. Guessing is how people end up with exclusions on folders that were never the problem, and never remove them again.

If the macro writes its file twice in a row from a cold start, you are done. The next section explains the four gates a file operation has to pass and how to tell which one refused you.

Why it happens

VBA file operations are thin wrappers over ordinary Windows file calls. Opening a file for output, deleting one, or saving a workbook goes through the same path as any other application’s request and meets the same gates: the file’s own attributes, the permissions on the folder, any handle another process is holding, and any filter driver installed above the file system. Error 70 is what comes back when one of those says no, and the published message – “Permission denied” – is deliberately unspecific about which.

The neighbours narrow it down, and each has a published message worth knowing. 75 is “Path/File access error”. 76 is “Path not found”. 52 is “Bad file name or number”, which is about the handle or the name you passed rather than about rights. 55 is “File already open”, which on a second run almost always means the first run never closed what it opened. 57 is “Device I/O error”, which on a network path usually means the connection went away mid-operation.

The gate people miss is controlled folder access. Windows protects a specific set of folders by default – Documents, Pictures, Videos, Music and Favorites, for both the user profile and the Public profile – and an application that has not been allowed through cannot write into them however good its permissions are. Note what is not on that list: the Desktop. A macro that writes to the Desktop and fails is failing for some other reason, and time spent on ransomware protection there is time wasted.

Full reference

Which one is yours

The numbers and what each rules in

What controlled folder access actually protects

• The user’s Documents, Pictures, Videos, Music and Favorites folders.
• The Public profile’s Documents, Pictures, Videos and Music folders.
• The same profile folders for system accounts such as LocalService and NetworkService.
• Folders you add yourself under protected folders in Windows Security.
• Not the Desktop, which is why a macro writing there and failing has a different cause.

When a write is refused you get a notification saying unauthorised changes were blocked, naming the application, and an entry appears in Protection history. Those two are how you confirm this cause rather than assume it. The remedy is to allow the specific application through, not to remove protection from the folder.

Closing files properly

Dim fn As Integer
fn = FreeFile

On Error GoTo CleanUp
Open "C:\Work\out.txt" For Output As #fn
Print #fn, "line one"

CleanUp:
If fn <> 0 Then Close #fn
If Err.Number <> 0 Then MsgBox "Write failed: " & Err.Description

FreeFile removes the collision between two routines that both hard-coded number one. The close in the cleanup path is what stops error 55 on the second run, and it has to run whether the write succeeded or failed – which is the whole reason for the error handler.

Things that look like fixes and are not

• Running Office as administrator. It masks the problem, hides drives mapped by the ordinary session, and creates files the normal user then struggles to manage.
• Excluding the whole user profile from scanning. That is most of the interesting file system, including where downloads and attachments land.
• Clearing read-only on a file that is read-only because it is open somewhere else. The attribute is not what is refusing you.
• Retrying in a tight loop. If the cause is a handle, a retry with a brief pause helps; a tight loop just fails faster.

Every code this article covers

Confirm the fix worked

1. Run the macro twice in succession from a cold start of the host application, with no editor open.
2. Confirm the output file appears at the expected path with the expected timestamp.
3. Check Task Manager afterwards for any host process left running.
4. Run it as a normal user on a second machine, not as an administrator on the developer’s.
5. If controlled folder access was involved, check Protection history and confirm no new block was recorded.

Questions people ask about this