Full Disk Access is the macOS permission that generates the most confusion when a storage tool asks for it, because the request usually arrives with no real explanation of what it changes. This article covers what's actually blocked without it, what it unlocks, and how to decide whether a given tool's request is reasonable for what it's trying to do.
What the sandbox blocks by default
Apps distributed through the App Sandbox — the model Apple requires for Mac App Store apps and that many independent developers opt into voluntarily — start with access only to their own container and whatever folders the user explicitly grants through a file picker or drag-and-drop. Beyond that, a sandboxed app cannot read arbitrary paths on disk just because it asked in code.
Concretely, without any additional permission grant, a sandboxed storage tool can see:
- Folders you explicitly open through a system file picker (Finder's Open dialog, or drag-and-drop onto the app)
- Its own app container under
~/Library/Containers/
It cannot see, by default:
- Other users' home folders on a shared Mac
- System-protected data stores, including Mail and Messages databases
- Some directories under
~/Librarythat hold other apps' private data, even within your own home folder
This is deliberate. The sandbox model assumes an app should only see what you've told it to see, not everything your account has permission to read.
What Full Disk Access specifically unlocks
Full Disk Access is a broader grant, given through System Settings → Privacy & Security → Full Disk Access, that lets an app read most of the disk regardless of the sandbox's default restrictions — including other users' folders (with appropriate system permissions still respected) and several of the protected data stores mentioned above.
For a storage tool specifically, granting Full Disk Access typically means it can now walk paths it previously couldn't enumerate at all, rather than reporting them as empty. Whether that matters to you depends entirely on what you're trying to measure. If you're the only user on your Mac and don't need Mail or Messages storage broken down specifically, Full Disk Access may add very little to what a well-behaved sandboxed scan already shows you.
Why some folders showing "0 bytes" is a red flag either way
Here's the part that matters regardless of which permission model a tool uses. When a storage tool encounters a folder it isn't allowed to read — whether because of sandbox restrictions or because Full Disk Access wasn't granted — there are two honest ways to handle it and one dishonest one.
Honest: label the folder as inaccessible, and exclude it from totals rather than silently treating it as zero bytes, or at minimum flag that the reported number is incomplete.
Dishonest, or at best careless: report the folder as 0 bytes with no indication that this reflects a permission failure rather than an empty folder. This is worse than it sounds, because a 0-byte reading for a folder you know is large (say, another user account's home folder on a shared iMac) will make you distrust the tool's entire scan, when the actual problem is much narrower and easily fixed by a permission grant.
Before trusting any tool's totals, check how it behaves on a folder you know it can't fully read. If numbers look suspiciously low with no accompanying explanation, that's worth investigating before you act on them.
Deciding whether to grant it
A reasonable approach is to start without granting Full Disk Access, and only add it if you specifically need the tool to see something it's currently reporting as inaccessible — another account's storage on a shared Mac, for instance. Granting the permission is not risk-free in the abstract sense that any broad grant increases what an app could do if it were misbehaved or compromised, even though in a well-built tool it changes nothing about how carefully your data is handled otherwise.
It's also worth checking whether the tool explains, in its own permission request dialog or documentation, exactly what it will do differently with Full Disk Access granted versus not. A tool that asks for the broadest permission available "just in case," without being specific about what it unlocks, is asking you to trust it more than it's earned.
How the permission prompt itself should behave
macOS handles Full Disk Access differently from most other permission prompts. Rather than a single in-the-moment dialog you can approve with one click, granting it requires opening System Settings, navigating to Privacy & Security → Full Disk Access, and manually adding the app (often after being shown a system-triggered prompt that deep-links you there). This extra friction is deliberate on Apple's part — it's meant to slow down casual granting of a broad permission, and a legitimate app should explain, at the point it triggers that prompt, specifically why it's asking, rather than presenting the request with no context and leaving you to guess.
If an app requests Full Disk Access immediately on first launch, before you've done anything that would actually require it — before you've tried to scan a folder it can't otherwise reach, for instance — that's worth noticing. A more considerate design asks only once you've hit an actual wall the permission would resolve, and explains what that specific wall was.
Revoking access later
Full Disk Access, once granted, isn't permanent in a way that's hard to undo. You can remove any app from the Full Disk Access list in System Settings at any time, and the change takes effect immediately (sometimes after relaunching the app). If you granted a storage tool broad access to investigate a specific problem — checking another user's storage usage on a shared Mac, say — and don't expect to need that again, revoking it afterward is a reasonable, low-effort habit. There's no meaningful downside to only holding a broad permission for as long as you're actually using what it unlocks.
A short comparison
| Scenario | Sandbox-only access | With Full Disk Access |
|---|---|---|
| Scanning your own home folder | Full coverage in most cases | No meaningful difference |
| Scanning another user's home folder on a shared Mac | Blocked, folder inaccessible | Visible, subject to system permissions |
| Measuring Mail/Messages storage specifically | Blocked | Visible |
| System-protected paths | Blocked (by design, regardless of permission — some paths are protected by SIP) | Still blocked where SIP applies |
Note that Full Disk Access doesn't override System Integrity Protection. Some system paths remain closed to any app, permission grant or not, which is a separate and intentional layer of protection.
Where VolumeLens fits
VolumeLens runs inside the App Sandbox with no privileged helper process, and it labels folders it cannot read rather than reporting them as zero. That's true whether or not you've granted any additional permission — the app tells you what it saw and what it didn't, so a low number never gets mistaken for a genuinely empty folder. No admin password is required for anything the app does. If you want to see exactly how scanning and permission handling work before deciding what to grant, the free tier lets you try it directly — see the features page or download VolumeLens to test it against your own setup.