Runtime Error 70: Permission denied (File access locks)

VBA Runtime Error 70 occurs when a macro attempts to write to, rename, move, or delete a file or directory that the operating system has locked. This failure is triggered when a target file is open in another application, held open by a hidden background Excel process, marked with a Read-Only file attribute, or restricted by Windows folder permissions. To resolve Error 70, close any applications locking the target file, clear hidden background instances in Task Manager, remove Read-Only attributes using SetAttr, or route file output to a directory with full write permissions.

Fast-Fix: The 45-Second Solution

Excel VBA Runtime Error 70: Permission denied occurs when a macro attempts to write to, modify, or delete a file that is locked by another process, marked as read-only, or restricted by user permissions. To fix it, ensure the file is closed across all applications, remove read-only attributes, and verify folder write access permissions before running the code.

Quick Risk Snapshot

• Severity Tier: Moderate to High (halts macro execution mid-routine, leaving file operations incomplete).
• Is it safe to ignore? No. The macro will crash every time it encounters a locked or read-only file handle.
• Most common cause: Attempting to delete (Kill) or overwrite a file that is currently open in Excel, Word, Adobe PDF Reader, or an antivirus background scanner.
• Rare/Serious cause: Invisible background EXCEL.EXE processes (ghost instances) holding open file handles after a prior automated script crashed without closing workbooks properly.

What Escalates the Risk

Working in shared network environments or cloud-synced folders significantly increases the frequency of Error 70. When Microsoft 365 co-authoring or OneDrive sync is active, file locks can be applied dynamically while cloud servers index changes, see Fixing VBA errors caused by “OneDrive” autosave and temp file paths.

Furthermore, writing macros that launch background instances of Excel (Set appExcel = CreateObject("Excel.Application")) without rigorous error handling creates orphaned processes. If an automated script encounters a calculation failure and terminates without calling appExcel.Quit and Set appExcel = Nothing, the background instance remains running in system memory, holding an invisible lock on all files it opened.

Common Confusion Fix

Runtime Error 70 is frequently confused with adjacent file-handling errors:

• Runtime Error 70 (Permission denied): The target path is valid, but the operating system blocks write/delete access due to active locks, read-only attributes, or security permissions.
• Runtime Error 53 (File not found): The specified file path string cannot be located by the file system [INTERNAL LINK: S03C02.11 – Runtime Error 53: File not found (Dir function failures).].
• Runtime Error 75 (Path/File access error): Occurs when trying to create or write to a folder path that is invalid, missing root permissions, or mapped to an unreachable network share.
• Runtime Error 1004 (Cannot access file): Triggered when using Excel’s higher-level workbook object method Workbooks.Open on a file locked by a password or bad network connection, see Runtime Error 1004: “Cannot access the file ‘filename.xlsx'” (Pathing issues).

What To Do Right Now

1. Click Debug in the error popup to highlight the line causing the failure.
2. Open Windows Task Manager (Ctrl + Shift + Esc) and check the Details tab for orphaned EXCEL.EXE or WINWORD.EXE processes. End these tasks to release invisible file locks.
3. Open Windows File Explorer, locate the target file, right-click it, select Properties, and uncheck the Read-only checkbox if enabled.
4. Verify whether another user on your network currently has the file open for editing.
5. In the Visual Basic Editor, use SetAttr strPath, vbNormal prior to executing Kill or file write operations.

Hard-Stop Triggers

Immediately halt testing and inspect system states if:

• The error occurs inside a loop that alters permissions across entire network shared drives.
• The file is stored on an enterprise server where modifying security attributes may violate corporate administrative policies.
• Multiple ghost EXCEL.EXE tasks continue spawning in Task Manager during testing, indicating a severe memory leak in your object initialization routines, see Excel Crashing on Close: How to properly clear Object variables from memory.

Professional Audit Path

To eliminate file access permission failures across production macros:

1. Test File Lock States Programmatically: Build a dedicated helper function to verify whether a file is locked before executing write or delete operations: VBA Function IsFileLocked(FilePath As String) As Boolean Dim FileNum As Long Dim ErrNum As Long On Error Resume Next FileNum = FreeFile() Open FilePath For Input Lock Read Write As #FileNum Close #FileNum ErrNum = Err.Number On Error GoTo 0 If ErrNum <> 0 Then IsFileLocked = True Else IsFileLocked = False End If Function
2. Automate Attribute Management: Always use GetAttr and SetAttr to inspect and strip vbReadOnly flags before modifying files programmatically.
3. Audit FileSystemObject Usage: If using Scripting.FileSystemObject, verify that every TextStream object opened with fso.OpenTextFile is explicitly closed with .Close before attempting to move or delete the file, see Handling “ActiveX can’t create object” when using FileSystemObject.
4. Implement Defensive Error Trapping: Wrap batch file operations in structured error handlers (On Error GoTo) to report locked files gracefully without aborting the entire process, see Using On Error Resume Next vs. On Error GoTo 0 (The right way).

Symptom Escalators

• If file handling fails because the specified file path cannot be located on disk, see Runtime Error 53: File not found (Dir function failures).
• If background Excel automation scripts leave orphaned processes in Task Manager after crashing, review Excel Crashing on Close: How to properly clear Object variables from memory.
• If FileSystemObject fails to initialize during file permission checks, check Handling “ActiveX can’t create object” when using FileSystemObject.
• If cloud synchronization locks disrupt file moves on OneDrive, consult Fixing VBA errors caused by “OneDrive” autosave and temp file paths.

Final Calculation

VBA Runtime Error 70 is an operating system security enforcement triggered when code attempts to modify a resource that is locked or marked read-only. It is readily resolved by ensuring all file handles are closed, terminating orphaned background processes in Task Manager, clearing Read-Only attributes with SetAttr, and checking file lock states programmatically before executing file operations.