You plug in a drive that worked yesterday and Windows says “Location is not available — X:\ is not accessible. Access is denied.”
This error is unusual because it covers two situations that could not be more different. One is a five-minute fix with no risk. The other is a failing drive, where the standard five-minute fix actively hurts you.
Telling them apart first is the whole job.
The benign version: NTFS permissions
NTFS stores permissions as security identifiers — SIDs — tied to specific user accounts on specific machines. Your account on your old computer and your account on your new computer are different SIDs even if both are named “Josh.”
So a drive that was used on another machine, or on an installation of Windows you’ve since reinstalled, can carry permissions that don’t recognize you. Windows sees files owned by a stranger and refuses access. Nothing is broken; you’re just not on the list.
Signs it’s this one:
- The drive shows up normally in Disk Management with the correct file system (NTFS, not RAW)
- You can see folder names, you just can’t open them
- The drive was recently moved between computers, or Windows was reinstalled
- No noises, no slowness, no errors before this
- The properties dialog shows folders with an unresolved SID instead of a username
The fix: right-click the drive → Properties → Security → Advanced → change Owner, and apply to subfolders. Or takeown and icacls from an admin prompt. Both are metadata-only changes and safe on a healthy drive.
The other version: the drive is failing
Access denied is also what Windows says when it can’t read the security descriptors — because the metadata region holding them is damaged, or because the sectors holding them won’t read.
Signs it’s this one:
- The drive was slow, noisy, or throwing I/O errors beforehand
- It also shows RAW or reports 0 bytes
- The error is inconsistent — sometimes you get in, sometimes you don’t
- File Explorer hangs for a long time before producing the error
- It happened after a power loss or an unsafe eject rather than after a machine change
Here, taking ownership is the wrong move. Applying new permissions recursively means writing to every file record on the volume — potentially millions of small writes to a drive that is failing to read reliably. That’s a lot of stress on struggling hardware, and if the write pass fails partway you now have a partially rewritten security structure layered on top of the original corruption.
Free evaluation. Firm quote before any work begins.
The third possibility: encryption
A BitLocker volume on a machine that doesn’t have the key can produce access errors too. If the drive was set up on a work computer or a newer Windows machine, check that before assuming corruption — what to do about a BitLocker prompt is here.
How to decide
Ask one question: was the drive behaving normally right up until this?
If yes, and the only thing that changed was which computer it’s plugged into, it’s permissions. Take ownership and get on with your day.
If it was slow, noisy, disconnecting, or had thrown any errors in recent weeks — or if the error arrived after a crash rather than after a move — treat it as a failing drive. Power it down and image it before running any permissions operation across the whole volume.
When you genuinely can’t tell, the safe order is the same one that’s always safe: image first, then experiment on the copy.
The bottom line
Access denied on a healthy drive is a Windows account mismatch and a trivial fix. Access denied on a degrading drive is a symptom, and the trivial fix becomes millions of writes to hardware that’s already failing. The drive’s recent history tells you which one you have.
Not sure which one you’re looking at? Start a case — tell me whether the drive was moved between computers or whether it started acting up on its own. That’s usually enough to call it.