Read-only, locked, or blocked: three problems behind one symptom
Access refuses to save, opens the database read-only, or blocks an action in disabled mode. Most of the time the file is fine and the cause is Windows, a lock file, or a Trust Center setting.
November 6, 2026 · 8 min read · Permissions · Trust Center · .laccdb · Multi-user
Three problems, one symptom
“I can’t edit anything” is the sentence that starts most of these searches, and it describes at least three unrelated situations. Separate them before changing anything: the usual advice for one of them, run Compact and Repair, writes to the file and is the wrong move for the other two.
| What you see | What it usually is | What the file is doing |
|---|---|---|
| A message bar offering Enable Content, or an action refused as blocked by disabled mode | Trust Center / Protected View | Nothing. The file is intact and not trusted yet. |
| It opens, but saving is refused, or it says it opened read-only | A Windows permission or attribute, occasionally a stale lock | Nothing, in most cases. Access is being denied write access to the folder. |
| Record(s) cannot be read; no read permission on 'MSysObjects' | System-table permission, or a damaged catalog | Either the account lacks rights, or the catalog page is unreadable. |
Blocked by disabled mode
When Access opens a database whose content it does not trust (downloaded from the internet, received by email, or produced by another machine) it disables the active parts: macros, action queries, some expressions. The data is fully readable; anything that would execute is refused, and the message names disabled mode rather than permissions.
The wording turns this into a corruption story: a query that ran yesterday is suddenly “blocked”. It was a trust decision, made per file, and it resets when the file arrives from a different source.
- 1
Look for the message bar before you look anywhere else
A bar under the ribbon offering
Enable Contentis the whole answer. If it is not there, the file is trusted and your problem is elsewhere. Do not go hunting in settings. - 2
If the bar is missing, check where the file came from
A file that arrived through a browser download, an email attachment, or a sync client can be held in Protected View. Opening it after copying it to a local folder, and confirming you trust the source, resolves this without touching the database.
- 3
Only change Trust Center settings deliberately
The path is
File → Options → Trust Center → Trust Center Settings, with separate pages for Protected View and macro settings. Turning protection off globally is the usual internet advice and it is a bad trade: you are disabling the check for every database you will ever open, to fix one file.
If Enable Content fixes it
If enabling content makes the database editable again, the file was never damaged. You do not need a repair tool, and running one on a healthy file only introduces risk. The fix here is a setting, not a product.
Read-only because of Windows
Access needs more than read access to a database. It needs to create and delete a small lock file next to it (.laccdb for .accdb, .ldb for .mdb), which means the account needs modify rights on the folder, not just read rights on the file. A folder where you can open but not create files produces the read-only behavior people describe, with no error that mentions permissions.
Microsoft’s own troubleshooting note (KB 283849) is blunt about this: the lock file records which records are locked and by whom, and it is removed after the last user exits. It survives that exit in two cases: the last user did not have delete permission on the folder, or the database is corrupted. Either case leaves a lock file behind.
- File attribute. Right-click the file, Properties, and look at Read-only. A tick there is enough to make Access open read-only even with full folder rights.
- Folder rights. If the database sits in a share where your account can read but not write, Access will not be able to keep a lock file and will fall back to read-only.
- How it was opened. The Open dialog remembers the last choice; if it was
Open Read-OnlyorOpen Exclusive Read-Only, every later open can inherit it. - Read-only media. Anything opened directly from a mounted archive, a CD, or a sync folder marked read-only behaves the same way.
- Split databases. A front-end whose linked tables point at a back-end you cannot write to will accept edits locally and refuse to save them.
The test that separates Windows from damage takes a minute: copy the file to a local folder you own, open the copy, and try to edit. If the copy is editable, the database is fine.
Locked, in use, or a stale lock file
Locks produce the same complaint and have nothing to do with damage. Two shapes occur. The ordinary one is a second session: someone else (or a second copy of Access on your own machine, left running behind a window you closed) holds the file. The other is a lock file left behind after a crash, which makes Access believe a session still exists.
Before deleting anything, confirm the file is not still in use: check for a running MSACCESS.EXE process, and check whether the person who had it open is still connected. Deleting a live lock file on a shared database is how a read-only complaint turns into a corrupted one.
A deleted or orphaned lock file is harmless, since Access recreates it on the next open, but it must only be deleted when nobody is connected, and the account doing it needs delete permission on the folder. If the lock file cannot be deleted because of permissions, Access reports read-only instead, which is the overlap between this section and the previous one.
No read permission on MSysObjects
MSysObjects is the catalog: the table that lists every other table, query, form and report in the file. Access reads it to draw the navigation pane. When that read fails, the message looks like a permissions problem, and sometimes it is one: workgroup security, or an account without rights on the system tables.
It is also what catalog damage looks like, and the two are easy to confuse because the message is identical. The distinguishing question is whether the same file behaves differently for a different account or on a different machine. If it fails the same way everywhere, permissions are not the explanation; the catalog page itself is unreadable.
Damaged catalog, intact tables
A damaged catalog is the difference between “I cannot list your tables” and “your tables are gone”. The data pages are frequently still there. What is lost is the index that says where they are, which is the layer a page-level reader can work around, and the layer Access’s own repair cannot, because it starts by reading that same index.
When the file really is damaged
Three signs point at the file rather than at Windows: the failure follows the file to another machine; Compact and Repair either refuses to start or finishes reporting that objects could not be repaired; and the errors change shape: different tables fail on different attempts, or the file opens but a specific table cannot be read.
At that point the relevant guide is what “unrecognized database format” checks: the first bytes tell you whether the problem is a version, a truncated header, encryption, or structure, and only the last of those is repair territory.
What this tool will not do
This is a browser-based reader, not an unlock utility. It cannot change Windows permissions, disable Trust Center protection, or recover a password, and it deliberately does not promise to “unlock” a database. In most of the cases above, the database was never locked in the first place.
What it does is answer one question without installing anything: is this file readable, and if so how much of it. It reports per table the rows the database declares, the rows read back, the rows reached but not safely parseable, and the rows never reached, plus ten real rows you can look at. If the catalog cannot be parsed, the report says so: that is the signal that you are in the damaged-catalog case above, and not in a permissions case that a settings change would fix.
Limits of this version
- It does not guess passwords. Password-protected files are reported as such; there is no bypass.
- It does not rebuild forms, reports, macros, or VBA. Those objects are read as text where the file allows it, but a working application is not reconstructed.
- A recovered database is written as a new Access 2000/2003
.mdb— the container this engine can write itself. Modern Access versions open it directly. - Very large databases can fall outside the current envelope. When a table cannot be written, the report says so per table instead of shipping a partial table as if it were complete.
If you still have the file
Read the evidence before you pay for anything
Drop the database into the check and you get, per table, the rows the file claims, the rows read back, and the rows that could not be parsed, plus ten real rows you can inspect. It runs inside the browser tab, so the file is never uploaded. Exporting what was recovered is $29 once, and only if the numbers look worth it to you.