Organizing an external drive not working: what to check, in order

Sorting out an external drive goes wrong in a specific way. Nothing crashes and no error explains itself. Files open normally but refuse to be renamed. A copy runs for eleven minutes and then stops on one file. A search returns nothing even though the document is plainly sitting in the folder. The drive is not obviously broken, so the natural reaction is to try the same action again, which produces the same result.

These are not one problem. They are five or six unrelated problems that happen to surface while doing the same task, and each one has a different first check. Guessing costs time. Worse, guessing sometimes leads straight to reformatting a drive that had nothing wrong with it.

Name the symptom before touching anything

The fastest move is to pick exactly one symptom and stop describing the situation as "the drive is not working". The symptom decides where to look, and it also rules things out.

Symptom	What it rules out	First check
Drive does not appear at all	Permissions, format, indexing	Cable, port, power, Disk Utility with all devices shown
Opens fine, cannot rename or move	Cable, hardware	Format, then volume ownership
Copy stops partway through	Permissions on the whole volume	File size, characters in the name, power
Files exist but search finds nothing	Hardware, permissions	Whether the volume is indexed
Works in Finder, fails in the terminal	Hardware, format	The actual path, and what owns the files
Repeated "not ejected properly"	Format, permissions	Disk sleep settings, and what still holds the volume

When several symptoms appear at once, start at the top row. A drive that connects and disconnects intermittently makes every lower row unreliable, because half the failures are just the disconnection showing up in a different costume.

Recognised is not the same as mounted

A drive missing from the Finder sidebar has not necessarily gone unnoticed by the Mac. There is a state in between, where the hardware is seen but no volume is mounted, and it looks identical from the desktop.

Open Disk Utility and choose Show All Devices from the View menu. The default view hides the physical device and shows only mounted volumes, which is exactly the information needed here. If the device row appears, the cable, the port and the enclosure are all doing their job. If a volume row appears beneath it in grey, the volume exists and is unmounted. diskutil list in a terminal shows the same thing in text form.

If nothing appears in either place, the problem is physical, and there is an order to that too:

Try a different port, on a different side of the machine. Try a different cable, since cables sold for charging often carry no data lines at all. Remove any hub or dock and connect straight to the Mac. For a desktop sized drive, confirm the power adapter is actually connected and the drive has spun up.

Bus powered 2.5 inch drives are the usual suspects for a device that appears and vanishes on a loop. Through a hub, available power can sit right at the edge of what the drive needs under load, and the result is a mount and unmount cycle rather than a clean failure.

Read only has two separate causes

Files open, previews work, and every rename, move and delete is refused. Two different things produce this, and they need different fixes.

The first is the format. macOS mounts NTFS volumes and reads them, but does not write to them as shipped. A drive that came from a Windows machine behaves exactly this way, and nothing about it is faulty. Select the volume in Disk Utility and the format is shown in the information panel. If it reads NTFS, the options are to move the contents somewhere else and reformat, or to add write support.

The second is ownership. An external drive carries the user and group IDs of whatever machine wrote the files. Plugged into a different Mac, or used under a different account, those IDs do not match the current user, and writes get denied even though the format supports them. Select the volume in Finder, open Get Info, and look at the bottom of the window for the option to ignore ownership on this volume. Turning that on makes the Mac stop consulting the recorded owner, which is the normal setting for a drive that travels between machines.

If the refusal applies to one folder rather than the whole volume, neither of the above is responsible. That is ordinary permissions on that folder, visible under Sharing and Permissions in the same Get Info window.

When Finder can do it but the terminal cannot

This one confuses people the longest, because the drive is clearly writable and the exact same operation works through the graphical interface.

The usual cause is the path. External volumes mount under /Volumes/, using the volume name, and that name is not always what is expected. If a volume with the same name is already mounted, or was not cleanly unmounted, macOS appends a number, so the drive that says Archive in the sidebar is actually at /Volumes/Archive 1. Commands aimed at the original path then act on a stale mount point or fail outright. ls /Volumes settles it in one line.

Spaces in the volume name are the second cause. /Volumes/My Archive/project is three arguments to a shell unless it is quoted. Finder never has this problem, so the name went unnoticed for months.

Ownership shows up here in a different form than in the previous section. Ignoring ownership on a volume changes how the Mac presents file owners, but a script that checks or sets permissions can still behave unexpectedly on such a volume, because the recorded owner and the effective owner no longer agree.

There is also the reverse case, where the terminal succeeds and Finder appears not to have noticed. Finder caches directory contents, and a folder written to by a command sometimes keeps showing the old listing until the window is refreshed. The files are there. The display is behind.

Run First Aid in the order it is documented

If the connection is solid, the format is right and writes are permitted, but behaviour is still erratic, the structure of the volume itself is worth checking. Disk Utility's First Aid does that, and the order matters.

Apple's documentation states that verifying and repairing a disk means running First Aid on each volume and each container on the storage device in turn, and then on the storage device itself. Running it on the visible volume alone is not the complete check, because inconsistencies can sit in the container layer above it.

The same page is explicit that Disk Utility cannot detect or repair every problem a disk can have. A clean First Aid result is not a certificate of health. It narrows the possibilities, which is all it claims to do.

If First Aid reports failure, and reports the same failure on a second run, the next step is not a third run. It is copying whatever can still be read to another location. Repair operations write to the disk, and every write against a failing disk is a chance to lose something that was still readable. If a warning appears saying the disk is about to fail, that disk has moved from the repair category to the replacement category.

A copy that stops partway

Large transfers fail for a small number of reasons, and they are quick to eliminate.

File size against the format. A FAT formatted volume cannot store a file larger than 4 GB. Move a folder of video and most of it succeeds while individual files fail, which looks arbitrary until the sizes line up.

Characters in file names. exFAT and FAT cannot represent colons, slashes and question marks in names. A name that macOS accepted without complaint gets rejected on arrival.

Power and heat. A bus powered drive taking hundreds of gigabytes in one continuous write can drop off the bus partway. Connect it directly rather than through a hub, and use the power adapter if the enclosure has one.

Sheer file count. Tens of thousands of small files makes per file overhead dominate, and the remaining time estimate becomes meaningless. An operation that looks frozen is often still progressing. The disk activity figures in Activity Monitor answer that in a few seconds.

For transfers at this size, the thing worth having is not a faster copy but a resumable one, so a failure at the ninety percent mark does not mean starting over.

Files that only one machine can see

Two variations of this turn up while moving material between systems, and both look like data loss.

The first is extra files. Writing to an exFAT or FAT volume, macOS stores metadata it cannot put in the file system itself into companion files beginning with a dot and an underscore, alongside a .DS_Store file recording folder view settings. These stay invisible on a Mac and appear as clutter on a Windows machine, roughly doubling the apparent file count. They are safe to delete from the Windows side, at the cost of losing the metadata they carried. Nothing is corrupt in either view.

The second is the opposite: files that were definitely copied and are nowhere to be found. Check whether the destination is a case sensitive volume and the source was not, or the reverse. APFS is offered in both case sensitive and case insensitive forms, and a folder holding Report.pdf and report.pdf collapses to one file when copied to a volume that treats those as the same name. Whether a warning appears depends on how the copy was performed.

A third variant is worth a glance in passing. Deleting files on an external volume moves them to a hidden trash folder on that volume rather than removing them, so free space does not change until the Trash is emptied while the drive is connected. A cleanup that appears to have accomplished nothing has often accomplished exactly what was asked.

The drive that keeps disconnecting

An eject warning appearing when nothing was unplugged usually means the drive put itself to sleep and the Mac read that as a disconnection. Check the energy settings for the option that puts hard disks to sleep, and note whether the warnings arrive at regular intervals, which points at a backup schedule waking the drive rather than at failing hardware.

The opposite complaint, a volume that refuses to eject because it is in use, is a question of what still holds it open. Closing the obvious document is often not enough, since previews, indexing and background sync all count. lsof /Volumes/DriveName lists the processes still attached to it, which turns a vague refusal into a specific application to quit.

What to change first

Pick one row from the table at the top and work only that row today. The common thread across all of them is the amount of switching involved: a Disk Utility window to see the device, a terminal to check paths and open files, a file window to act on the result, and attention split three ways. A file manager with a built in terminal collapses two of those, because the folder on screen is the working directory, including on an external volume, which is what Features describes and what Compared with other file managers sets against the alternatives. Before adding anything, Atriens and tools like it are worth checking against what the free part already covers.