First stop: Check the drive's firmware version
I've seen this error more times than I can count, and nine times out of ten it's a firmware bug in the tape drive itself. Had a client last month with an HP LTO-6 drive in a Quantum i6000 library that threw this the moment they tried to load a tape. Drove them nuts for three days before I checked the firmware—it was from 2014.
Here's the fix: grab the latest firmware from your drive manufacturer's site. For HP LTO drives, go to https://support.hpe.com. For IBM, https://www.ibm.com/support. For Quantum libraries, you'll need their support portal. The firmware update process varies by model, but for most, you'll download a .bin file and use the library's web interface or a tool like hp_tape_fw_update.exe.
One gotcha: some drives need the firmware update applied while the library is in service mode. Don't do this during a backup window—you will break things. I learned that the hard way at 2 AM on a Saturday.
Second most common culprit: the tape drive driver
Even if the firmware is current, Windows can hose the driver. Happens most often after a Windows Update or a fallback to a generic driver. The symptom: the drive shows up in Device Manager but the inject/eject port throws 0x10E9.
Fix it like this:
- Open Device Manager (
devmgmt.msc). - Expand Tape drives.
- Right-click your tape drive and choose Update driver.
- Select Browse my computer for drivers.
- Pick Let me pick from a list of available drivers on my computer.
- If you see two or more entries, pick the one from the drive's manufacturer, not the generic Microsoft driver. For HP drives, look for
HP LTO-6 Ultrium Tape Drive. For IBM drives,IBM LTO-5 Tape Drive. - Install it and reboot.
Pro tip: if you only see a generic Microsoft driver, download the proper driver from the manufacturer's site and install it manually by pointing the wizard to the .inf file.
Third cause: library communication timeout
This one's sneaky. I've seen it happen when the tape library's Ethernet or Fibre Channel connection is flaky, or when the library's management processor is overloaded. The error shows up because the Windows driver sends a command to open or close the port, but the library doesn't respond in time.
Check these things:
- Ping the library's management IP to see if it drops packets. Run
ping -t [library_ip]for a minute. If you see timeouts, blame the network. - Log into the library's web interface and check for logged errors. Look for
SCSI command timeoutsorLUN errorson the drive slot. - If it's a SAS drive directly connected to a server, try a different cable or a different SAS port on the HBA. I swapped a cable once and the error vanished.
If you find network issues, replace the cable or the switch port. If the library's management processor itself is slow, a power cycle of the entire library (not just the drive) sometimes clears the cobwebs. But don't power cycle during a backup—that's a different disaster.
Quick-reference fix table
| Cause | Likelihood | Fix |
|---|---|---|
| Outdated firmware | High | Update tape drive firmware to latest version |
| Wrong or corrupted driver | Medium | Reinstall manufacturer's specific driver |
| Library communication timeout | Medium | Check network cables, power cycle library |
One more thing: if none of this works
I've had two cases where the drive itself was just dying. The inject/eject mechanism physically failed. On HP LTO drives, you can sometimes hear the motor trying to engage and failing—a soft clicking noise. On IBM, the port just stays stuck. If you've ruled out firmware, drivers, and network, it's time to replace the drive. Don't throw good money at a bad drive.