The external hard drive adds a few levels of complexity over internal drives. An external hard drive housing will have an interface card inside it that will convert the hard drive data between that native to the drive and the type of interface being used (USB, Firewire, Thunderbolt, etc.) Additional cabling and connections are used both inside the external drive housing as well as the I/O cables used to connect the external drive to the computer. An external hard drive will either have an external power supply or derive its power from the I/O port connected to the the external drive. Many external drives also use drivers that may or may not be the sources of problems. The tests performed during interface tests and memory/system bus tests in Diagnostics Mode exercise completely different system components but they are not mutually exclusive. Problems that are exclusively related to the hard drive inter-connections, such as the I/O cables and connectors or I/O controller logic board traces will rarely show up in system bus tests, but problems with the system bus or memory will likely also show up in interface tests as well because the logic board itself or something connected to the logic board is causing the problems.

If problems are detected in one or both tests, refer to the section titled Dealing with Problems for more information. Incompatibilities may exist between some implementations of a hardware interface and that implemented in the operating system. For example, in Mavericks we've had reports of USB drives that can't be seen by the system becoming 'visible' if they're plugged into a USB hub, which in turn is plugged into the system. Essentially the USB hub is acting like a 'Mavericks adapter.'

Whether this problem is cause by a problem with the operating system or the hardware is unknown. If possible, always check the external drive on other I/O ports (if available) or even other systems to ensure the drive is actually working. If the resets fail to produce positive results, the first thing that needs to be determined is whether or not the drive is visible to the system at all.

If the external drive is the primary boot drive, this usually requires booting from install media (if available), another bootable drive (usually external), or if you're a Scannerz user and you've created a Phoenix Boot Volume, then that can be used to boot the system. If the drive is a secondary drive, then the tests should be done from the primary boot drive. Once the system is up, Disk Utility should be brought up to see whether or not there's any indication of the drive being present.

External Drive Ejected By Imac And Keeps Running Back

If the drive shows up in Disk Utility, it indicates that the drive is visible to the system. It may show up with a volume name as a valid Mac volume, or it may show up with only a disk designation only (such as disk0s2.) If the drive shows up only with a disk designation, it typically implies either the drive is damaged from bad sectors, the index files are so corrupt that it can't be properly seen by the system, or possibly has been reformatted with a foreign operating system Mac's aren't familiar with. At this point it can't hurt to use Disk Utility to run checks on the drive, but keep in mind that it's not a surface scanning tool - it will only be trying to see if it can repair a bad drive index. If an index repair works using Disk Utility, you might be able to resume using the drive. If Disk Utility indicates there are no errors with the drive and it's being used as a boot drive, it likely indicates that some of the critical boot files have either been deleted or lost in bad sectors. If Disk Utility fails its verification and/or repair of the drive, the drive index files may be too corrupt to be repaired and/or there may be bad sectors on the drive. If the drive can't be dealt with properly using Disk Utility, you might want to use Scannerz to try and perform a surface scan on the drive, particularly the first few gigabytes, to see if it's registering any errors.

Follow the steps described in the preceding section to accomplish this. If the drive registers surface scan errors, more than likely the drive needs to be repaired or replaced.

This needs to be confirmed using Scannerz in Diagnostics Mode to ensure the problems are sector and not cable related. The first few gigabytes of a volume typically contain all the boot code and libraries needed to bring the system up. If bad sectors are detected and confirmed, see the section titled Dealing with Problems on the base page of this set of articles. If the drive is a boot drive and a Phoenix Boot Volume has been created for emergency evaluation, it should be used to run Scannerz tests on the drive. Some drives will not allow the user to deliberately or fully utilize all the controls of a drive unless the drive's own firmware and software is installed in the unit. This can be problematic if the operating system gets updated and the manufacturer doesn't provide updates for the software in a timely manner.

If such a drive is put into use very often it may put itself to sleep without regard to operating system settings. When the user attempts to access the drive, the drive needs time to reactivate itself and spin up, which may take tens of seconds. Sometimes, if the drive is in this type of sleep mode, even attempting to save a file may end up taking tens of seconds. Since the power consumed by the drive is related to the drive speed, another way to save power is to reduce the spindle speed of the drive and vary it with data access. Data rate transfers can be directly correlated to the spindle speed, and if the drive is using a lower speed to save power, the data rate will be correspondingly lower.

Under heavy use, these drives typically 'ramp up' to full speed, and slow down when under light or no load. Under light or no load, this can effectively make the drive appear to be very slow at times. If you suspect an external drive has any of these problems, we recommend visiting the manufacturers web site to see if there's any information about the suspected problem. Additionally, you might be able to find information on the web about other users having similar problems which might confirm that the problem is not unique to your unit. If the drive seems to be in working order, you may wish to use the back button on your browser and visit the page titled User Problems for more possibilities.

If the problems are truly related to the drive heads, platters, cables, connectors, or logic board traces running between the logic board I/O controller and the external drive connector or any of the cables or connections used both internally and externally to the external hard drive housing, they will have one or more of the symptoms identified in items 1, 2, 3, 4, 6, 9, and 10. If this is the case, see the section below titled Problems with the External Hard Drive, Support Circuitry, or the Logic Board. When a drive needs to read or write data to an external drive, the CPU on the logic board sends a set of commands to the drive through what's called an I/O controller. The I/O controller, which is on the logic board, is usually connected to an external drive via an interface cable, logic board traces, or a combination of both, all leading to the I/O connector (USB, Firewire, Thunderbolt, etc.) on the logic board. Depending on the age of the system, there may be other circuitry on the logic board, such as additional USB or Firewire interface circuitry that may be inserted between the I/O controller path and the actual interface connector. From the I/O connector data flows through the external drive's I/O cable until it enters the external drive interface adapter and makes it's way to the hard drive's controller.

The commands the I/O controller issues are fairly high level, such as 'get me this number of blocks of data between points A and B on the drive' or 'write the following blocks of data to the drive between points C and D.' This is obviously an over simplification. Once the I/O controller delivers the commands, it's the duty of the drive controller to implement them and return the appropriate response codes, and in the case of read operations, data back to the system. Additionally, with an external drive it's possible that if intermittent connections or short circuits exist in the data lines, the data passed between the system and the drive may be corrupt. Unfortunately, this can also be caused by problems with the supply regulation in the external drive. An erratic or marginal power source may fail to properly convert binary ones and zeros to their appropriate values during the transition between the actual hard drive and the interface card inside the external enclosure.

If intermittent problems exist with an external hard drive, the first possible source that should be looked at is the external drive cable itself. If a copy of Scannerz is already available, putting it into Diagnostics Mode using the interface testing mode may easily expose problems.

Cursory Mode may also be useful. This is described in more detail below. The nice thing about external drives is that you have access to the cable and it can be moved around or strained during tests to see if problems exist. In Diagnostics Mode, you may actually be able to observe errors being induced into the system as the cable is moved around. External drive ports on the logic board (those that you plug your external drive into) are often subjected to impact or strain damage.

Although a user may not think they're putting terrible strain on a port connector by bumping it slightly or connecting a drive to it that can 'barely reach' the port, the connections on the logic board are tiny and they can crack quite easily. If there are multiple ports on a system, trying the external drive on another external port may yield positive results, but if that's the case it also indicates that the problematic port is now likely unusable. Problems of this nature may appear and go away as the system heats and and cools, respectively. Another problem with external cables are the connectors themselves. Many people think that I/O connectors have infinite lives, but they don't. Many interface connectors, such as USB and Firewire connectors, rely on the elasticity of metal to provide the 'springiness' that allows the tabs in the connector to make electrical contact with the host port.

As the cable is plugged and unplugged the connectors lose the 'springiness' and start to intermittently fail to make consistent electrical contact. The symptoms will be nearly identical to a cable with an intermittent short or break, and the solution will be the same - replace the cable. Wobbling the cable connectors during a Scannerz test in either Diagnostics or C ursory Mode may generate a flood of I/O errors or inconsistent timing irregularities which will expose the problem. Important Note: If an external drive appears to have failed completely, do not assume the drive itself inside the enclosure is dead. It's entirely possible the I/O card or supply regulation circuitry inside the enclosure might have failed. The only way to confirm this is to extract the hard drive from it's enclosure and evaluate it.

If an external hard drive has confirmed bad or weak sectors as tested using Scannerz, that doesn't necessarily mean the drive can't be read and data cannot be recovered. Since many hard drives may contain data like credit card numbers, be careful!