You plug in an external drive and can read files but can’t save to it. Or a drive that worked fine on your other Mac won’t let you write on this one. Or you’re asked for your password every time you try to access certain folders on an external drive.

Permission issues on external drives are confusing because the rules are different from your Mac’s internal storage. macOS applies ownership and permissions to external volumes in ways that aren’t always intuitive.

How macOS handles ownership on external drives

Your Mac’s internal drive has a clear owner: you. Your user account has an ID number (usually 501 for the first account created), and that ID is stamped on every file you create.

External drives carry their own permission stamps from whatever computer last wrote to them. If you created files on a Mac where your user ID was 501, and you plug the drive into another Mac where you’re also user 501, everything lines up. But if the IDs don’t match, you get permission conflicts.

This is common when sharing drives between multiple Macs, especially in work environments where user accounts are set up differently on each machine.

Ignoring ownership on external volumes

macOS has a built-in solution for the ownership mismatch problem. Select the external drive in Finder, press Command-I to open Get Info, and look for “Ignore ownership on this volume” at the bottom.

When this checkbox is enabled, macOS treats every file on the drive as if it belongs to the current user. It bypasses the ownership stamps entirely. This is the default for most removable APFS and Mac OS Extended (HFS+) drives, which is why you usually don’t encounter permission problems.

Note that this checkbox only appears for APFS and HFS+ volumes. It does not appear for exFAT or FAT32 drives, since those filesystems have no native permission system.

If this setting got turned off (which can happen after formatting or after certain macOS updates), permission errors start appearing. Turn it back on and the problems go away.

Note: you need administrator access to change this setting. If the checkbox is grayed out, click the lock icon at the bottom of the Get Info window and enter your password.

APFS permissions vs exFAT permissions

APFS drives carry full POSIX permissions: owner, group, and world access flags for read, write, and execute. They also support Access Control Lists (ACLs) for more granular control. This is the same permission system your Mac’s internal drive uses.

exFAT drives have no permission system at all. Every file is accessible to everyone. This sounds like it would eliminate permission problems, but macOS sometimes synthesizes permissions for exFAT volumes, which can create unexpected behavior.

When macOS mounts an exFAT drive, it assigns ownership to the current user and applies default permissions. Usually this works fine. But if the mount process encounters an error or the drive has filesystem damage, the synthesized permissions can be wrong.

If an exFAT drive suddenly becomes read-only, the issue is usually filesystem corruption rather than permissions. Run Disk Utility’s First Aid to check and repair it.

Full Disk Access and external drives

macOS Ventura, Sonoma, and Sequoia enforce Full Disk Access restrictions more strictly than previous versions. These restrictions affect how applications interact with external drives.

Full Disk Access is a privacy setting that controls which apps can access the full contents of your storage, including external drives. Without Full Disk Access, an application might be able to open files you explicitly give it but can’t browse the drive’s contents freely.

This matters for ejection because diagnostic tools like Terminal need Full Disk Access to see all processes using a drive. Without it, the lsof command shows incomplete results. You run lsof on your drive, see nothing blocking it, but still can’t eject because the actual blocker is hidden from Terminal’s view.

Grant Full Disk Access to Terminal (or your preferred terminal app) in System Settings > Privacy & Security > Full Disk Access. This ensures you get the full picture when diagnosing ejection issues.

When permissions prevent ejection

Permission problems don’t usually prevent ejection directly, but they cause indirect ejection failures.

If a process tries to write to your external drive and hits a permission error, it might retry repeatedly instead of failing cleanly. Each retry attempt keeps a file handle open. The process is effectively stuck in a loop, unable to complete its operation or release the drive.

You’ll see this pattern with backup software, sync services, and system processes like Spotlight. They try to write metadata or index data to the drive, get denied by permissions, and keep trying.

Fixing the underlying permission issue (usually by enabling “Ignore ownership on this volume”) resolves the ejection problem too.

Repairing permissions on external drives

The old “Repair Disk Permissions” feature in Disk Utility was removed in macOS El Capitan. It only ever applied to system files on the boot drive, so it was never relevant for external drives despite widespread misconception.

For external drives, the closest equivalent is resetting ownership and permissions manually:

sudo chown -R $(whoami) /Volumes/YourDriveName/
sudo chmod -R u+rw /Volumes/YourDriveName/

This gives your user account ownership and read-write access to everything on the drive. Only do this on personal drives, not on shared drives where other users need to maintain their own permissions.

For a less aggressive fix, just enable “Ignore ownership on this volume” as described earlier.

Encrypted drives and permissions

If your external drive is encrypted with APFS encryption, you need the encryption password to mount it. But after mounting, permissions work normally.

FileVault-encrypted external drives can occasionally develop permission issues if the encryption metadata gets out of sync. If you’re experiencing permission errors on an encrypted drive, try locking (ejecting) and unlocking (mounting with password) the drive. This forces macOS to re-establish the encryption context and often resolves permission anomalies.

Making it all work together

Permission issues, ejection failures, and filesystem errors often compound each other. A permission error causes a background process to stall, which blocks ejection, which leads to an improper disconnection, which causes filesystem damage, which creates new permission errors.

Breaking this cycle starts with proper ejection. When your drive won’t eject and you suspect permission issues are involved, Ejecta can identify the stalled process and let you quit it cleanly. From there, fix the underlying permission issue so the problem doesn’t recur.

Permissions on external drives are simpler than they seem once you understand the ownership model. Most problems are solved by a single checkbox. But when something more complex is going on, knowing where to look makes all the difference.