Runtime Error 70: “Permission denied,” explained and fixed
Error 70 — “Permission denied” — means the program asked Windows for something and Windows said no: writing to a locked or read-only file, deleting a file that's open, creating a file in a protected folder, or reaching a network share without rights. It's a door being locked, not a program being broken — the job is finding which lock.
The usual locks, most common first
- The file is open somewhere — in the program itself, in Excel/Word, or by another user on the network. Writes, renames, and deletes all fail against an open file.
- The file is read-only — the attribute is set (common for files copied from email, archives, or old media).
- The folder is protected — Program Files, the Windows folder, and another user's folders all refuse writes from ordinary programs by design.
- Network permissions — the share allows reading but not writing or deleting, or the connection silently dropped to guest access.
- The program tried to kill/delete a file it opened earlier and never closed — a code-level lock of its own making.
The fix
- Close everything that might hold the file. Check the taskbar and Task Manager for the program, Office apps, and previews. On a network, ask who else has it open — or check the server's open-files list.
- Check the read-only flag: right-click the file → Properties → clear “Read-only” if ticked.
- Move working files out of protected places. Data a program edits belongs in Documents or a data folder, never in Program Files. If legacy software demands it, that's a vendor conversation — but relocating its data folder setting (most have one) is the clean fix.
- Verify share permissions by trying the same action in File Explorer: if Explorer can't save there either, the program was never the problem — the share's permissions are.
- For coders: close what you open (
Close #n, release objects) before Kill/Rename, and expect locks: attempt the operation, and on error 70, tell the user which file is locked instead of crashing — the file name is the fix instructions.
Running everything as administrator is not the fix. It papers over one lock while creating security problems and sometimes new failures (mapped drives disappear under elevation, for example). Fix the specific lock.
If it still happens
Use the file name as the search key: find what's holding it. Sysinternals Handle (from Microsoft) can name the exact process locking a file when Task Manager can't. If the lock is the program's own earlier session — a crashed instance still running invisibly — ending that process in Task Manager releases the file immediately.
Common questions
Is error 70 a security warning? No — it's an ordinary refusal: a lock, an attribute, or a permissions boundary doing its job. It becomes a security topic only if the program is asking for access it should never need.
Why does it fail on the network but work locally? Share permissions are separate from folder permissions on the server; both must allow the action. A read+write share over a read-only folder still refuses writes.
Related errors