Runtime Error 75: “Path/File access error,” explained and fixed
Error 75 is the file system saying no — in the older VB/VBA dialect. A statement tried to open, write, rename, or delete a file and was refused. It's error 70's (“Permission denied”) close sibling, raised by a slightly different set of statements, and the refusals come from the same short list of causes.
The usual refusals, most common first
- The file is read-only — the attribute is set (files copied from archives, email saves, and version-control checkouts are frequent carriers) and the code tried to write or delete it.
- The file is open elsewhere — another program, another user on the network, or the same program holding it from an earlier, unclosed open.
- The target is a folder, not a file — a path missing its file name, or a trailing backslash turning a file path into a directory path.
- The location is protected — writing into Program Files or system folders from a standard-privilege process.
- A rename across drives or onto an existing file —
Name statements can't overwrite, and can't move between drives; both surface as 75.
The fix
- Reproduce it by hand. Try the same action in File Explorer on the same path — rename it, open it, save to it. Explorer's clearer error message usually names the lock or the permission directly.
- Check the attribute: right-click → Properties → “Read-only.” In code, clear it deliberately when it's yours to clear:
SetAttr path, vbNormal before writing.
- Close holders: confirm no other instance (including a crashed, invisible instance of the same program in Task Manager) holds the file; close your own earlier handles — every
Open needs its Close, including on error paths.
- Append the file name if the path ends at a folder, and delete-then-rename (or use FileSystemObject's CopyFile with overwrite) when replacing an existing file — the
Name statement won't do it.
- Move the working location out of protected folders for data the program edits regularly.
Running as administrator treats one symptom and hides the cause. If the refusal is a lock or an attribute, elevation doesn't help at all; if it's a protected folder, the durable fix is relocating the data, not permanent elevation.
If it still happens
Log the exact path and operation at failure time (Debug.Print both). Error 75 disagreements are always concrete: one path, one verb, one lock. With those three written down, the Explorer test identifies the lock in under a minute — the error only stays mysterious while the path stays assumed.
Common questions
What's the difference between error 75 and error 70? They're near-identical refusals from different statement families: 70 comes from object-model and permission-checked operations, 75 from the classic file I/O statements (Open, Name, Kill, MkDir-era code). The causes and fixes overlap almost completely.
Why does it happen on the second run but not the first? The first run leaves something behind: the output file now exists (read-only, or open, or blocking a rename). State created by run one is the classic trigger — test with the output deleted to confirm.
Related errors