Runtime Error 70: Permission denied (File access locks).

VBA raises Runtime Error 70: Permission denied when code attempts to write to, replace, rename, or delete a file, folder, or system resource, but the operating system or file system blocks the operation. This is caused by operating system file locks, read-only file attributes, conflicting background processes, or lack of Windows administrative write permissions in the target directory.

Quick Answer

To resolve Runtime Error 70, close any programs (including other Excel instances) currently holding an open lock on the file, remove the “Read-only” attribute from the file’s properties in Windows Explorer, save into directories that do not require elevated administrative privileges (avoid the root of C:\ or C:\Program Files\), and ensure you close file input/output streams using Close #fileNumber before re-accessing them.

---

Root Causes of Permission Denied

Unlike generic pathing errors, Runtime Error 70 means the file was located successfully, but the operating system refused to complete the requested action due to security or access rules:

' Fails with Error 70 if Sales.xlsx is currently open in Excel or another process:
Kill "C:\Data\Sales.xlsx"

1. Active Application Locks: The file is open in another Excel instance, Word, Adobe Acrobat (common with exported PDFs), or an automated backup utility.
2. Ghost Excel Instances: An orphaned EXCEL.EXE process running in the background (visible in Windows Task Manager) holds an exclusive lock on the file.
3. Read-Only File Attribute: The file has the physical vbReadOnly attribute enabled on disk.
4. Folder Permission Constraints: The user account running the macro lacks “Modify” or “Write” permissions on the destination folder (such as network shares with restricted ACLs or protected system folders).
5. Unclosed VBA I/O Channels: Using legacy file commands (Open ... For Output As #1) and attempting to modify or delete the file before calling Close #1.

---

Troubleshooting and Remediation Steps

Step 1: Kill Orphaned Excel Background Processes

If a previous macro crashed or failed to terminate cleanly, it may leave behind a hidden background process:

1. Press Ctrl + Shift + Esc to open Windows Task Manager.
2. Look under the Details tab for any instances of EXCEL.EXE.
3. If Excel is not actively open on your screen, select the orphaned process and click End Task.

To prevent background automation tasks from hanging on exit, review Building a “Reset” macro to fix Excel settings after a crash (Calculation, ScreenUpdating)..

Step 2: Clear Read-Only File Flags Programmatically

If your macro needs to overwrite or delete files that may be flagged as read-only, remove the attribute using SetAttr before running the operation:

Sub ForceDeleteFile(filePath As String)
    On Error GoTo FileError

    If Dir(filePath, vbReadOnly + vbHidden + vbSystem) <> "" Then
        ' Strip ReadOnly, Hidden, and System attributes
        SetAttr filePath, vbNormal

        ' Delete the file safely
        Kill filePath
    End If
    Exit Sub

FileError:
    MsgBox "Failed to delete: " & Err.Description, vbCritical
End Sub

Step 3: Handle Locked Shared Workbooks

If your macro updates files on shared network folders, another user may have the file open. You can check for a file lock before attempting destructive write operations:

Function IsFileLocked(filePath As String) As Boolean
    Dim fileNum As Integer
    On Error Resume Next

    fileNum = FreeFile()
    ' Attempt to open the file exclusively
    Open filePath For Binary Access Read Write Lock Read Write As #fileNum
    Close #fileNum

    ' If an error occurred, the file is currently locked by another process
    If Err.Number <> 0 Then
        IsFileLocked = True
        Err.Clear
    Else
        IsFileLocked = False
    End If
End Function

If lock contention issues are widespread across your network models, see “The file is locked for editing”: How to kill “Ghost” owner files (~$filename). and “Sharing Violation”: Why Excel won’t let you save over an existing file..

Step 4: Always Close Open File Channels

When reading or writing text or CSV files using low-level file I/O, wrap the operation in structured error handling so that the channel closes even if a runtime error occurs:

Sub WriteTextFileSafe()
    Dim fNum As Integer
    fNum = FreeFile()

    On Error GoTo ErrorHandler
    Open "C:\Logs\run.log" For Append As #fNum
    Print #fNum, Now & " - Process Completed."
    Close #fNum
    Exit Sub

ErrorHandler:
    ' Ensure the file channel is never left locked in memory
    Close #fNum
    MsgBox "File I/O failed: " & Err.Description, vbCritical
End Sub

---

Diagnostic Summary Table

Error Code	Primary Cause	First-Line Fix
Runtime Error 7: Out of memory	Oversized Variant arrays; unmanaged large matrices; 32-bit address space exhaustion.	Use typed arrays (Long, Double); free memory with Erase; batch process data in chunks.
Runtime Error 53: File not found	Calling Kill or FileCopy on an empty string; Dir() returning filename without path.	Concatenate the directory path with Dir(); verify file existence before deleting.
Runtime Error 70: Permission denied	File open in another program; read-only attribute active; unclosed file I/O channel.	Remove read-only flags using SetAttr; close open file streams; end orphaned EXCEL.EXE processes.

---

Next Diagnostic Steps

If your file read/write routines fail during automated network refreshes, check Runtime Error 1004: “The file could not be accessed” (Network drive timeouts)..

If your macros encounter unexpected errors when executing system-level actions, verify that your script uses appropriate error-trapping methods as outlined in Using On Error Resume Next vs. On Error GoTo 0 (The right way)..

To build automated alerts that capture and log operating system file errors before they halt execution, refer to Building a Global Error Handler: The Err.Number and Err.Description guide..