How to hash files on an external drive on Mac
A file on a USB disk, an SD card or a network share hashes to exactly the same digest it would on your internal SSD — Rocket Hash reads it where it lies. What changes is the permission macOS wants first, the speed you get, and the fact that a volume can vanish halfway through.
The drive is mounted, the files are sitting there in a Finder window, and as far as you are concerned they are no different from anything in your home folder. Three things disagree: macOS guards removable and network volumes with their own permission, the bytes arrive an order of magnitude more slowly, and a volume can disappear mid-sentence in a way your internal disk never does.
None of that changes the answer. A digest is a function of the bytes, so the same file hashed on a USB stick, an SD card, a NAS share and your internal SSD gives you four identical digests — the filesystem, the volume name and the drive's age have nothing to do with it. What changes is how long you wait and what can interrupt you.
This page covers hashing files where they are, rather than copying them over first, and why that distinction is the whole point when what you are testing is the drive.
If the question is “is the copy on this drive still good?”, copying the file to your Mac and hashing that copy answers a different question. Read it from the drive.
What actually changes when the bytes are elsewhere
- Permission. Desktop, Documents, Downloads, removable volumes and network volumes each sit behind a separate grant on a modern Mac. A sandboxed app does not get the run of your disks, and the first attempt to read one is the moment that gets settled.
- Speed. Not by a little. A USB hard disk hands over around 120 MB/s where SHA-256 can consume roughly 2 GB/s, so for the whole run the arithmetic is idle, waiting on the cable.
- Volatility. An internal SSD does not get unplugged by somebody reaching for a charger, and it does not spin down, sleep, or vanish when the Wi-Fi drops.
Hash files on an external volume
-
Mount it and check the volume name
Plug the drive in, or connect the share, and let it appear in the Finder's sidebar. Note the volume's name — you will want it in a moment to prove you hashed the copy you meant to. If you have two drives called
Backup, rename one now and save yourself an afternoon. -
Drag the files in from the volume
Open the Files tool and drag the file or folder across from the Finder window showing the external volume. Dragging does two useful things at once: it grants access to exactly what you dropped, which is the quickest way past the permission question, and each row then shows the containing folder under the file name — so you can see at a glance that you picked up the copy on the drive rather than a same-named file in
~/Downloads. -
Let it run without touching the drive
Set the Algorithm control and start it. Then leave the drive alone: no copying in the background, no ejecting, no closing the lid. The status bar counts files on the left and progress on the right, and a long run over USB will spend most of its life waiting on reads rather than on anything your Mac is doing.
-
Compare the two ends
A digest on its own proves nothing; it is the comparison that does the work. Either use the export button to write a
shasum-compatible manifest from each side and diff the two lists, or put the original and the copy into the Verify tool's File vs. File mode and read the verdict. Comparing two files directly covers the second route.
Permission, and the quickest way past it
macOS treats a removable volume as somewhere an app has to be invited. Dragging files in from the Finder is an invitation, and it is per-item: drop a single file and that file is readable, drop the volume's folder and everything under it is. That is usually all the ceremony you need.
Where it gets tedious is a job you repeat — the same backup disk, every month. There the grant you want is the standing one in System Settings rather than a fresh drag each time, and permission denied when hashing a folder covers which switches matter and which do nothing. Either way, the app has no network access at all, so nothing about reading a NAS share involves the app phoning anywhere — it reads a mounted volume exactly as any other program would.
USB disks, SSDs and memory cards
The number on the box is the bus, not the drive. A 10 Gbps port attached to a spinning disk gives you a spinning disk's speed, and that gap is where most surprises live.
| Drive | What actually sets the speed | Check first |
|---|---|---|
| Portable SSD | The cable and port, usually | That it is not plugged into a hub shared with something busy |
| Portable hard disk | The platters — 100–130 MB/s, whatever the port | Whether it had spun down and is still waking up |
| SD or CF card | The card, then the reader | The reader: a cheap one halves a fast card |
| NAS or SMB share | The network, and everyone else on it | Wired versus Wi-Fi, before anything else |
| Cloud-synced folder | Whether the file is really on this Mac | Whether reading it triggers a download |
Hashing is a pure sequential read, which makes it an honest measure of the drive: start a large file and the throughput figure on screen is roughly what that drive can do. Reading the speed and time remaining covers turning that number into a wait, and what to do when it comes in well under the table above.
Network shares and cloud folders
A mounted share behaves like a disk until you give it a lot of small files, at which point every open and close becomes a round trip over the wire. Gigabit Ethernet tops out near 110 MB/s on one big file and can fall to a fraction of that on ten thousand tiny ones, which is why a folder that takes two minutes locally can take half an hour across the room.
When a sync service is set to free up space, what is left on disk is a placeholder. Reading the file pulls it down, so hashing a folder of evicted files can quietly start a 200 GB download before it computes anything.
That is worth checking before you start rather than after. If the run crawls and your upload meter is busy, the bottleneck is not hashing. For anything in that situation, hash the source you control and keep the manifest — exporting a manifest and checking the far end against it later is much cheaper than streaming everything twice.
The extra files macOS leaves on a USB stick
This catches people comparing a folder at both ends. Copy files from an APFS disk to an exFAT or FAT-formatted stick and macOS stores the parts that filesystem cannot hold — extended attributes, resource forks — in a companion file beside each one, named with a ._ prefix. It may also leave a .DS_Store, a .Spotlight-V100 folder, an .fseventsd and a .Trashes on the volume.
Your real files are unaffected: the data itself is copied byte for byte, so every digest still matches. But a folder run on the stick produces a longer list than the same folder run on the Mac, and if you diff the two manifests blindly it looks like the copy grew. It did not. Ignore the dot-prefixed entries and compare the rest — or compare per file rather than per folder, which is what the verify after a transfer route does.
Reading a drive you do not want to disturb
Hashing writes nothing. No byte is changed, no modification date is touched, nothing is moved or created, which makes it safe to point at an archive disk, a client's drive or a card you have not offloaded yet — see does hashing change a file for why that is true rather than merely usually true. A full-size SD card's write-protect tab and an NTFS volume's read-only mount are no obstacle at all, for the same reason.
That read-only guarantee is what makes the archival use work: hash the drive now, keep the manifest, and a year from now the same run tells you whether anything on it has quietly decayed. Verifying a backup covers that cycle, including which disk the manifest should not live on.
Troubleshooting
The app cannot see the volume
Confirm the Finder can, first — if the drive is not mounted, nothing downstream will find it. If the Finder shows it and a file picker does not, you are looking at a permission grant rather than a hardware problem, and dragging a file across from the Finder window is the one-second way to prove it.
The same file is ten times slower here than on the internal disk
That is the expected result, not a fault. SHA-256 at roughly 2 GB/s is waiting on a drive delivering 120 MB/s, so you are measuring the cable and the platters. If you need the job finished faster and you are going to keep the files anyway, copy them to the internal disk first and hash there — but remember that then proves the copy is intact, not the drive.
The drive disconnected part way through
A run has nowhere to read from and stops. Nothing is damaged, because nothing was being written at either end. Reconnect, check the file is the size you expect, and start that file again; a byte offset is only useful while the bytes behind it are reachable, which is also why a paused run cannot survive the drive being pulled.
The copy on the drive does not match the original
Check the copy has actually finished first: a Finder copy that is still running leaves a file of the right name and the wrong length. After that, confirm you hashed the right two files — the folder line under each row is there for exactly this — and check you are not comparing a file with its ._ companion. A genuine mismatch after all that usually means a failing drive or a bad cable, and the sensible next move is to copy it again and see whether the mismatch is reproducible.
A few files fail and the rest are fine
Unreadable files in an otherwise healthy run point at the medium rather than at anything else: bad sectors on an old disk, a card that has been in and out of a camera for five years. Note which files they are, get what you can off the drive now, and stop using it for anything you care about.
Frequently asked questions
Can I checksum files on a USB drive without copying them to my Mac first?
Yes, and for most purposes you should. Reading the file from the drive is what tells you the copy on the drive is intact; copying it to your Mac first and hashing the copy tests the copy instead. The only reason to copy first is speed, and then only when you wanted the files locally anyway.
Why is hashing files on a network drive so much slower?
Every byte crosses the network, and every file costs a round trip to open and close. Gigabit Ethernet peaks near 110 MB/s on a single large file and drops sharply on thousands of small ones, against several gigabytes a second from an internal SSD. The arithmetic is idle the whole time — the wire is the bottleneck.
Does hashing files on an external drive change anything on it?
No. Hashing is a read from start to finish: no byte is written, no modification date changes, nothing is created or moved. That holds for write-protected SD cards and for NTFS volumes that macOS mounts read-only, which is why neither is an obstacle.
Why does a Mac app need permission to read an external drive?
Because macOS puts removable and network volumes behind their own privacy grant, alongside Desktop, Documents and Downloads. A sandboxed app gets access to what you hand it rather than to everything mounted. Dragging files in from the Finder hands over exactly those files, which is why it works immediately.
Can I hash files on a drive formatted for Windows?
Yes. A digest is computed from a file's contents, so exFAT, FAT32, NTFS and APFS all produce the same value for the same bytes. Filename case rules and timestamp precision differ between those filesystems, and none of that is part of the digest.
Is it safe to unplug the drive while files are being hashed?
Nothing will be damaged, because hashing never writes — but the run stops and the file in progress has to be started again. Let it finish, or stop the run first and eject properly. On a long job, keeping the Mac awake matters as much as keeping the cable in.
What are the ._ files that appear when I hash a folder on a USB stick?
They are companions macOS writes on filesystems such as exFAT and FAT that cannot store extended attributes and resource forks natively. Your real files are copied byte for byte and their digests still match; the extra entries simply make a folder listing on the stick longer than the one on your Mac. Ignore the dot-prefixed names when you compare two manifests.