Permission denied when hashing a folder on Mac

You dragged a file in and it hashed in a second. Then you dragged in the folder that file lives in, and either nothing arrived at all or the run finished having quietly skipped part of the tree. Nothing about the second attempt was more ambitious than the first, which is what makes it so irritating.

Reading a file on macOS has to clear four independent checks, and they have very little to do with one another. Unix ownership and mode bits. Access control lists layered on top of those. The privacy system that fences off Desktop, Documents, Downloads and every volume you plug in. And, for anything from the App Store, the sandbox, which starts from the position that an app may read nothing of yours at all. Underneath, macOS splits them into two pairs — mode bits and ACLs refuse with EACCES, the privacy system and the sandbox with EPERM — though those are kernel return codes rather than anything on screen. What you can triage is where the folder lives. One of those three folders, a volume you plugged in or a share means the privacy system and the sandbox, which is the first half of this page. A folder anywhere else that you have handed over and still cannot read is the Unix layer underneath, and the second half is the one you want.

Gate by gate, then. The sandbox comes first, because it is the one that explains why a single file sailed through and its own folder did not. Then the three switches in System Settings that change something, the one everybody reaches for that changes nothing, and the Unix layer sitting underneath all of them. If the folder is on a USB disk or a NAS, hashing files on an external drive covers the rest of that situation; if it stalls rather than refuses, hashing a folder is about the run itself.

Why a Mac refuses a read

Four gates, each with its own rules and its own remedy. Naming the one you hit is most of the work.

• Ownership and mode. The original Unix layer: every file has an owner, a group and nine permission bits. A folder you cannot execute cannot be listed at all, even when the files inside it would be perfectly readable. It bites on material copied from another Mac, where the numeric user ID in the files does not match yours.
• Access control lists. macOS layers ACLs on top of the mode bits, and an entry that denies reading beats mode bits that allow it. Directories restored by a backup tool, or inherited from a file server, are where you meet them.
• Privacy permissions. Desktop, Documents and Downloads, removable volumes, network volumes and other apps' data each sit behind a separate consent, granted per app, the first time that app asks. This is the only layer with switches in System Settings.
• The App Sandbox. A Mac App Store app runs with no standing access to your documents whatsoever. It reads what you hand it and nothing else — not as a matter of policy, but because the kernel will not let it.

There is a fifth gate that does not negotiate at all. System Integrity Protection seals /System, much of /private/var/db and the operating system's own innards against every process on the machine, root included. A scan refused down there is not a problem to solve. It is the answer.

What the sandbox lets through

The sandbox widens in exactly one way: you, personally, indicating a thing. Two gestures count.

• Dragging from the Finder. Drop a file and the app may read that file. Drop a folder and it may read everything inside it, however deep the tree goes — the cheapest grant available, and it needs no settings pane.
• Choosing in an open panel. The add (+) button in the Files toolbar — one of the four controls in the window tour — opens a standard macOS panel, and whatever you select is handed over with the same effect as a drag. Select the folder rather than its contents and you get the whole subtree.
• Nothing else. A path typed as text is not a grant, and neither is a location an app worked out for itself. No setting anywhere converts a sandboxed app into one that can wander off on its own.

Which is the honest trade. The reason Rocket Hash can be pointed at a folder of confidential material without much thought — no network access anywhere in it, nothing reachable that you did not hand over — is precisely the reason it sometimes refuses a folder you felt sure you had already allowed. The first property is not available without the second.

Grant access to a whole folder

1. Drag the enclosing folder, not the files

   Go up one level in the Finder and drag the parent folder across, rather than selecting the files inside it. Forty thousand individual grants and one folder grant cost the same single gesture, and the folder grant also covers files that appear in that tree later. Even when the refusal came from four levels down, the grant you want is the one at the top.

2. Answer the privacy prompt the first time

   If the folder is on the Desktop, in Documents, in Downloads, on a USB disk or on a share, macOS interrupts with a consent dialog naming the app and the location. Allowing it records a standing permission for that pairing and you are not asked again. Declining records the refusal just as permanently, which is the origin of most of the rest of this page.

3. Turn the switch back on in System Settings

   Open System Settings ▸ Privacy & Security ▸ Files and Folders and find the app in the list. Its row expands into one switch per location — the Desktop, Documents and Downloads folders, plus Removable Volumes and Network Volumes. Turn on the one that matches where your folder actually lives, which is not always where you assume: an external disk mounted under /Volumes is a removable volume whatever its icon looks like.

4. Quit the app and open it again

   Privacy answers are cached per process, so a switch flipped while an app is running may change nothing until that process starts again. Quit the app completely rather than closing its window, open it again, then re-add the folder and watch the status bar: the summary on the left counts what you handed over, the progress on the right counts what has been hashed. When the two agree, every file in the tree was readable.

The three switches that matter

Every privacy switch relevant to hashing lives in one pane, and there are three of them. The only thing separating them is where the bytes physically are.

Two absences catch people out. Your home folder outside those three subdirectories needs no privacy grant at all, so something in ~/Projects will never prompt. The sandbox still applies, so you still have to hand the folder over — but once a drag has done that and the read is still refused, the gate is Unix, and the section below is the one you want. And iCloud Drive is a protected location in its own right, which is why a folder that syncs behaves differently from the same folder copied to your Desktop.

Full Disk Access, and what it is actually for

This is the switch everybody tries first, and it is the wrong one. Adding a sandboxed App Store app to Privacy & Security ▸ Full Disk Access does not widen what it can read. Full Disk Access relaxes the privacy layer for a process; it does not relax the sandbox, and for a sandboxed app the sandbox is the tighter of the two. The app sees what you hand it, switch or no switch.

So the useful question is which location you were after. The switch exists for the few places macOS fences off from every program at once — Time Machine backups, ~/Library/Mail, another account's home folder, several corners of ~/Library — and a sandboxed app is never let into those. If that is where your material sits, copy what you need into a folder of your own and hash the copy. For a backup, it is the files you wanted checked rather than the backup's own innards — verifying a backup is that job.

The narrowness cuts both ways, which is the point of hashing files offline: an app that reads only what you hand it, over a connection it does not have, is one you can point at material you are not allowed to leak.

When it is not a privacy permission at all

If the folder is nowhere near Desktop, Documents, Downloads or a mounted volume, and dragging it in still fails, you are looking at ordinary Unix permissions — and those have nothing to do with System Settings. The Finder will tell you: select the folder, press ⌘I, and open Sharing & Permissions at the foot of the Get Info window. It names the owner, the group and what each is allowed; your own account showing No Access is the answer whatever else is set.

Two shapes turn up. A folder owned by somebody who is not you, closed deliberately and not yours to reopen. Or permissions restored by a backup tool or inherited from a file server, where an access control list carries an explicit denial that outranks the ordinary ones and survives changing them. The padlock in that window lets an admin rewrite the simple case; the second sort often will not yield there, and either way it is a tree you did not create.

The safer move for a one-off is to copy the folder into your own home directory and checksum the copy. Copying the data does not alter it, so every per-file digest is identical to the original's — that is the entire point of a content fingerprint, and what hashing does and does not touch explains why reading is the only thing happening in either case.

Troubleshooting

One file worked but the folder did not

Because a file grant covers exactly that file, which is also why a run can succeed on Monday and fail on Tuesday over a file added in between. Dropping report.pdf says nothing about its neighbors or its parent; drop the parent instead.

I declined the prompt and it never came back

Correct, and deliberate: macOS treats a refusal as an answer rather than a deferral, so it does not nag. The recorded decision is the switch in Privacy & Security ▸ Files and Folders; turn it on there and relaunch the app. Dragging the folder in from a Finder window also works immediately, because a drag is a fresh and unambiguous act of handing something over.

sudo did not help

It would not. Privacy permissions and the sandbox attach to the program, not to the user, so being root changes neither — and launching a GUI app under sudo leaves root-owned preference files behind for your normal account to trip over. Of the four gates it touches one, the Unix layer — and for a one-off the copy described above is less trouble than rewriting a tree's permissions.

The folder finished but files are missing from the list

Compare the two numbers in the status bar, then compare the left-hand one with what the Finder says the folder holds. The usual culprits are a volume mounted inside the tree you dropped, another user's directory nested within it, or a folder whose execute bit is off so its contents were never enumerable in the first place. Drop the awkward branch on its own to find out which.

The share mounts but the app still cannot read it

Two permissions that look like one. The credentials you gave the server let macOS mount the volume; the Network Volumes switch, or the folder you drag across from the mounted share, is what lets an app read from it. Mount the share, then drag the folder you want out of its own Finder window — a path you typed grants nothing, and nor does a bookmark that mounted it in the background.

Frequently asked questions

Why does a hashing app need permission to read my own files?

Because every App Store app starts with no access to your documents at all, and the only thing that widens it is you indicating a specific file or folder. That mechanism is what makes a sandboxed app safe to point at confidential material — it cannot read anything you did not hand over, so there is nothing to audit and nothing to take on trust. The cost of the guarantee is an occasional consent dialog.

Does Full Disk Access fix permission denied when hashing?

Not for a sandboxed Mac App Store app. Full Disk Access relaxes macOS privacy protection but not the sandbox, and the sandbox is the stricter of the two, so the app still reads only what you hand it. Nothing in System Settings changes that; the gesture that does is dragging the folder itself in from a Finder window, which grants the whole tree at once.

How do I give an app permission to a whole folder at once on macOS?

Drag the folder itself from a Finder window into the app instead of selecting the files inside it. That one gesture grants access to the folder and everything beneath it, including files added later. For a folder you return to every month, the standing equivalent is the matching switch under Privacy & Security, then Files and Folders, in System Settings.

Why can Finder see the folder when an app cannot?

The Finder holds permissions that no other app inherits — it is the program macOS trusts to show you your own disk. Every other app's access is granted separately and per location, which is why a folder you are looking at right now can still be refused to something else. Dragging it out of that Finder window into the app is the shortest route across the gap.

Can I hash files on an external drive without granting anything?

You still have to grant something, but a drag does it: dropping the file or folder in from the volume's own Finder window counts as consent for exactly that item. The standing alternative is the Removable Volumes switch, which is worth turning on if you checksum the same archive disk every month. Hashing files on an external drive covers the speed and disconnection problems that come with it.

Does a permission error mean the file is corrupted?

No. A refused read is a decision macOS makes before a single byte has been looked at, so it tells you nothing whatsoever about the contents of the file. Once the read is allowed you get the digest you would always have got — and if that disagrees with a published value, what to do when a checksum does not match is the page for it.