MacOS – External Hard Drive no longer working

disk-utilityexternal-diskmacos

I am on a MacBook Pro 13 running latest Sierra. I have an external Seagate solid state hard drive that was working and out of the blue stopped working. The only thing on it was my Adobe Lightroom images/videos. Not the LR DB files. I'm sure you have all heard this woe before, so I won't dwell on that. And yes, I back up to the cloud. AWS S3 specifically. Though I am traveling South East Asia for the last year, and staying in cheap hostels. So good internet is hard to come by sometimes. I can't back it up after every export. While most of it is backed up, there is some that is not.

Moving on. The symptoms seems to change every time I plug it in. The first sign was it ejected on it's own. I plugged it in again, and it wouldn't mount. Disk Utility recognized it, so did the command line diskutil list but it wouldn't mount. I rebooted and it worked for a second. Then I could only get to it from the command line. Then trying to frantically back up to my local what was not backed up to the cloud, it all failed. Basically just a cp -R [directory] [local-directory] command.

After some more frantic unplugging and re-plugging plus some command line manual mounts, I finally got it to where the Disk Utility would be able to run first aid on it. It failed. I don't recall the error. So I put it in a freezer. After a few hours I tried again. It is not any better. It still will not mount. Now Disk Utility sees it, but with no partition. I can't even give me information about how much space is used on it.

I have also tried it from a Windows machine. It did not mount. I have tried other cables. No success. As well as tried my other USB port. I also have another working external hard drive exactly like the one giving me issues. It works on all cables and USB ports.

I do have Docker running with a Ubuntu container, I'm trying to think of a way to see if I can try to get to the USB from there. I also have a USB that I have thought about running a live Ubuntu on there to see if I can mount and retrieve the data or fix the HDD that way. But if it will not mount, I doubt these will work.

Can anyone else think of any other tricks I can try myself to see if I can repair this or at least retrieve the data without paying for a service or software? If not, those suggestions are also welcome.

Update

I made the mistake in original post that it was a Solid State Drive. This is my mistake, it is actually a spinning disk hard drive. I bought them long ago and have been traveling with them for so long I just forgot. Question is updated to reflect this.
Now diskutil list does not show it at all. The Disk Utility app also does not see it.
Based on suggestion from @Allen I seeked out the USB to SATA cable. I did not quite find it, as my options are extremely limited where I am at. Though a local expat on a facebook group was able to help me with a empty 2.5 casing that I was able to extract the drive from original casing and put it in his blank case. It now mounts. Though it has the "click of death" sound to it. And data is not really reachable. While I can ls the directories and Adobe Lightroom does not have the exclamation mark when it can not reach the actual external files. Right clicking on the images and clicking on "Show in Finder" or any other variation of trying to get to the files through Finder or terminal, I have no success. It usually hangs and I get the spinning wheel. Since Adobe Lightroom imports these images into directories named by date, I am going to send the drive off to a data recovery service and ask to recover just unbacked up directories i.e. dates. Next time I will make harder efforts to backup and probably get an actual SSD.

I think this can be closed, due to my low reputation points I can not close this myself.

Best Answer

...any other tricks I can try myself to see if I can repair this or at least retrieve the data without paying for a service or software?

Based on everything you said, there are only two conditions that exist:

The USB enclosure has failed. This is the least bad scenario. The "enclosure" has a USB to SATA controller that is the interface of the drive. It's not out of the realm of possibility that it "reports" back the drive, but refuses to mount/read/write/etc.
The SSD drive itself has failed This is the worst case scenario. If the drive has failed, there's nothing you're going to do to force it to start working.

How can you find out which scenario is the one you're dealing with? I wrote an answer to a similar question that addresses this situation exactly. It involves a cheap USB to SATA adapter to remove the enclosure from the equation. If the drive works, it was the enclosure; you get the added benefit of the adapter being a temp solution until you get the enclosure fixed (or another external drive). If it doesn't work, then you know the SSD has died.

Related Solutions

Macbook Pro won’t mount external hard drive

This seems like an issue with the chosen file system.

What file system did you choose when formatting the hard drive? If it's not HFS(+), FAT in any fashion or NTFS you cannot read it on OS X without additional software. If it's Ext, you could go with Paragon's Ext for Mac (but it costs some bucks).

In future, best choose exFAT when formatting an external hard drive if you need to use it on different operating systems. It both allows rather large files (which is heavily limited in FAT32), but can be both read and written in all important operating systems.

MacOS – Hard drive no longer accessible

I suspect Windows` chkdsk or another Microsoft tool to erroneously repairing the partition table of your device containing the EXFAT volume.

The result of sudo gpt -r -vv show /dev/disk2 of my 4 TB device created in a VM and formatted with Disk Utility in comparison looks like this:

gpt -r -vv show /dev/disk2
gpt show: /dev/disk2: mediasize=4000655081472; sectorsize=512; blocks=7813779456
gpt show: /dev/disk2: PMBR at sector 0
gpt show: /dev/disk2: Pri GPT at sector 1
gpt show: /dev/disk2: Sec GPT at sector 7813779455
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640        2008         
      411648  7813365760      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  7813777408        2015         
  7813779423          32         Sec GPT table
  7813779455           1         Sec GPT header

(Please consider that the mediasize, the blocks and some other values are different to yours, because i use a slightly smaller example disk here.)

The differences to your finding are obvious: the first partition of your disk isn't aligned properly to the 4096 byte sector size and is smaller. The second partition starts too early and is probably too big.

You probably have to fix both partition. This will only work if you partitioned the drive with Disk Utility in Mac OS X.

Preparation:

Backup your Mac and then detach all external drives.
Download and install wxHexEditor. Enable the root user and log-in as root.

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.

Where does the EXFAT partition start and end?

First you have to determine the starting block of your EXFAT volume:

Open Terminal and enter diskutil list. Get the Identifier of the disk to repair.
Open Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber.
Hit the search button (marked with the red circle in the picture below) and enter EXFAT (exactly like in the picture). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.
My EXFAT entry (see picture below) is at offset 210763776. Now you can calculate the start block of the volume with: OffsetBytes/512 = NewStartBlockEXFAT. The start block in my example is 411648.

If you get a significantly smaller starting block (=<409639) stop here, because you probably didn't partition your disk with Disk Utility previously.
The ending block of the EXFAT volume can't be determined easily; we have to guess it (somehow). The problem is the variable gap between partition 2 and the second GPT table. In your case it has 1679 blocks, in my example it has 2015 blocks.
- Method 1 (maximal size in the "unallocated space" between the block containing the EXFAT string and the second GPT table):
  The maximal volume size is StartBlock2ndGPT-NewStartBlockEXFAT. The size has to be dividable through 8. Reduce the size until you get a size dividable through 8. Example: In my case the maximal size would be 7813779423 (StartBlock2ndGPT) - 411648 (StartBlockEXFAT) = 7813367775 (which isn't dividable through 8). The biggest size dividable through 8 is 7813367768.
- Method 2 (minimum size containing all occupied blocks between the block containing the EXFAT string and the second GPT table):
  You might jump to sector 7814037135 (the first block of your secondary GPT table) with the arrow button (the second button left of the search button) and search backwards and match case disabled with "Find some bytes" to get the last occupied sector. This may take a while. Make a note of your finding (if you have one in a reasonable timeframe). Divide the offset through 512 to get the sector number. The sector number should be smaller than 7814037135. Now calculate the provisional minimal size of your volume: StartBlockEXFAT+1-LastOccupiedSector. The result must be dividable through 8. To get size add blocks until the size is dividable through 8.
  You may stop the process after 5 minutes without result because then the last occupied block number is probably smaller than 7807917625 assuming the process searches 10 MByte/s (the last ~3 GB of your disk). Use Method 1 then.
Both results probably lead to a wrong size of the EXFAT volume, but this should be repairable. It's more important to get the proper start block. Additionally method 2 may deliver incorrect results if the disk has been completely filled with data previously using a different partition layout and hasn't been zero-filled afterwards.

Restoring the "old" GPT

Here i assume the identifier of the disk containing the EXFAT volume is disk0.

First you have to unmount the disk
```
diskutil umountDisk disk0
```

Check the partition layout, then remove the two partitions:

gpt -r -vv show /dev/disk0

gpt remove -i 2 disk0
gpt remove -i 1 disk0

Since the (Apple-)EFI usually has a fixed size we can easily add it with:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0

With the start block of the EXFAT partition and Size (the volume size found with Method 1 or 2 above) we can also add it:
```
gpt add -b NewStartBlockEXFAT -i 2 -s Size -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
```
Remount disk0 with:
```
diskutil mountDisk disk0
```
Quit Terminal, Calculator and wxHexEdit and open Disk Utility.
Check your EXFAT volume for errors.

If you run into problems (e.g you can't find the proper EXFAT volume size), have doubts or questions immediately stop and contact me with a comment @klanomath!

Best Answer

Related Solutions

Macbook Pro won’t mount external hard drive

MacOS – Hard drive no longer accessible

Related Question