The short answer
SharePoint turning read-only is almost always one of three things: your tenant has run out of storage, an administrator has deliberately locked that one site, or the person complaining simply has Read permission rather than Edit. They look identical to the user and need completely different fixes.
Count who is affected and you will know which one you have. One person is permissions. One site is a lock. Everyone, everywhere, is storage.
It usually arrives as a small complaint rather than an alarm. Someone cannot save a spreadsheet. A file refuses to upload. A document opens, but every change bounces back. By the time it reaches us, three or four people have tried the same thing and decided the internet is broken.
Picture it landing in an accounting practice in Cheltenham on the Monday of a BAS week. The work does not stop being due because the system stopped accepting it. That is why the first job is not to fix anything, it is to find out which problem you have.
Start by counting who is affected
This one question separates the three causes faster than any amount of clicking around.
- Only one person. Almost certainly permissions. Everyone else saving normally is the giveaway.
- One site or one team, everyone in it. Almost certainly a deliberate lock on that site.
- Everyone, across every site. Now you are looking at storage.
The third is the one people jump to, and it is the least common of the three. The first is the most common by a distance, and the cheapest to fix.
The most likely answer: it is permissions
SharePoint has permission levels that are easy to assign and easy to forget about. Somebody added to a site's Visitors group gets Read access: they can open documents, search and download, and they cannot create, change or delete anything. To that person, the site is read-only. To everyone else it is working perfectly.
There is a stricter level again called View Only, meant for people who should consume content rather than work on it. And there is Limited Access, which SharePoint assigns by itself when someone has been given access to a single file or folder rather than the whole site. Limited Access looks alarming in the admin console and is usually not a fault at all, it is SharePoint doing exactly what it should.
If one person is stuck and nobody else is, check what group they are in before you look anywhere else.
The second answer: somebody locked the site on purpose
Administrators can set a SharePoint site to read-only deliberately. It is a reasonable thing to do with a finished project site, an archive, or a set of records that should not change while something is being reviewed.
The problem is that these locks outlive the reason for them. A site gets locked during a handover, the handover finishes, and two years later somebody needs to add a file and cannot. If one site is affected and the rest of SharePoint is fine, this is where to look.
The third answer: you are out of storage
SharePoint storage is pooled across your tenant rather than allocated per site, and the amount you get is tied to your licensing. For the common Microsoft 365 business and enterprise plans, Microsoft's figure is 1 TB for the organisation, plus 10 GB for every licence you buy.
In practice that means:
| Licensed users | Pooled SharePoint storage |
|---|---|
| 15 | About 1.15 TB |
| 50 | About 1.5 TB |
| 100 | About 2 TB |
Two things surprise people about that table. The first is how little the per-user component adds: going from 15 staff to 100 only moves you from roughly 1.15 TB to roughly 2 TB. The second is that the allowance shrinks if you reduce licence count, which catches businesses out after a restructure.
What actually fills it up
Storage rarely fills because of the documents people think of as their files. It fills because of everything around them.
- Teams meeting recordings. The single biggest cause we see. Recordings land in SharePoint or OneDrive, nobody deletes them, and a year of weekly meetings is a serious amount of video.
- Version history. SharePoint keeps previous versions of every file. That is a feature worth having, and on large files with many edits it multiplies what you are storing.
- Scanned archives. Scanners default to settings that produce much larger files than anyone needs. A practice that scans everything at high resolution will outgrow its allowance years early.
- Old migrations. Content copied in from a previous file server, often twice, often including the folder nobody has opened since 2019.
- Recycle bins. Deleted content still counts toward your total until the bins are emptied, which is why a clean-up sometimes appears to achieve nothing.
OneDrive has a separate limit, and Microsoft tightened it
This is the part that catches businesses out, because it is a different pool with different rules. Your OneDrive storage is per user and set by that person's licence, and it is not drawn from the SharePoint tenant allowance.
In July 2026 Microsoft corrected the way that limit is enforced, so that quotas line up with what each licence actually entitles. Users who were sitting above their licensed amount, often because an administrator had raised their limit manually at some point, are placed into a read-only state until usage comes back under the line or the licence is upgraded.
So if a single person has gone read-only in their own OneDrive while SharePoint is healthy, that is this, and it is a licensing conversation rather than a clean-up.
Getting people writing again
If it does turn out to be storage, there are three routes, and most businesses need a combination.
- Reduce what you are holding. Clear out recordings nobody will watch, trim version history on the libraries that do not need deep history, remove duplicated migrations, and empty the recycle bins afterwards so the space is actually returned.
- Archive the cold content. Microsoft 365 Archive moves content you want to keep but rarely touch into a cheaper tier while leaving it searchable and restorable. It suits the case most businesses are actually in, which is having a lot of old material they are not willing to delete.
- Buy more storage. Additional capacity can be added to the tenant. Where the content is live and still needed, this is the honest answer, and it is usually cheaper than the hours spent arguing about what to delete.
Deleting first is the instinct, and it is the one that most often destroys something somebody needed.
The risk is continuity, not data loss
It is worth being clear about what read-only does and does not mean, because the word frightens people more than it should.
Nothing is deleted. Your files, versions and recycle bin contents all stay exactly where they are. What you lose is the ability to write, and that is quite enough: a business that cannot save a document, upload a file or collaborate in Teams has effectively stopped, even though every byte of its data is intact.
That reframes storage from a housekeeping chore into a continuity question, and continuity questions deserve to be monitored rather than discovered. Storage grows gradually and invisibly until the day it does not, which is the same shape as most of the problems we are brought in to clean up after.
We are based in Mornington and look after Microsoft 365 for businesses across Melbourne and the south east, and storage headroom is one of the things we watch as a matter of course rather than wait to be told about. If you are not sure where your tenant sits today, start a conversation and we will find out before it becomes a Monday morning.