Fix ERROR_CLEANER_CARTRIDGE_INSTALLED 0X000010F4 Tape Library

You walk in Monday morning, backups failed all weekend, and the library is throwing ERROR_CLEANER_CARTRIDGE_INSTALLED (0X000010F4). Translation from tape-library-ese: a cleaning cartridge is sitting somewhere it shouldn't be — usually still loaded in a drive, sometimes parked in a storage slot after an interrupted clean cycle. The library refuses to mount data tapes until it's resolved because the drive isn't truly empty.

I've hit this on IBM TS4300s, Dell PowerVault ML3s, and a couple of old Quantum Scalar i40s. The trigger is almost always the same: someone pulled a cleaning tape mid-cycle, a firmware update rebooted the library during a clean, or the library's auto-clean policy fired while the tape was still being moved. The drive reports cleaning media present and the whole partition goes read-only.

Cause 1: Cleaning cartridge still loaded in the drive (most common)

This is the one you'll see 8 times out of 10. The clean operation started, the robot pushed the cleaning tape into the drive, and then something interrupted it — power blip, SAN fabric drop, a backup server reboot, whatever. The drive never got the unload command, so it sits there holding the cleaner.

Fix it from the library's management interface first, not the backup software. Log into the web GUI (for IBM TS4300 it's the management IP on port 443), go to Manage Library > Drives, and check drive state. If it says "Cleaning" or "Media Present" with a cleaner, you need to force an unload.

In the CLI, IBM libraries use something like:

// From the library service CLI or Web UI Advanced
unload drive 1
or
move media source=drive1 dest=IE slot

If the drive is wedged and won't respond to unload, you cycle the drive — not the whole library. On IBM TS4300 that's Manage Library > Drives > Drive 1 > Power Cycle. Wait 90 seconds after it comes back before issuing any commands. I've seen people reboot the entire library and it doesn't help because the drive retains state across library reboots.

After the drive is empty, run a library inventory (often labeled "Rediscover" or "Inventory Library" in the GUI). That clears the 0X10F4 state.

Cause 2: Cleaner cartridge dropped into a data slot

Second most common. An operator — usually someone filling in for the regular tape guy — pulls the cleaner out of its dedicated cleaning slot and drops it into a normal data slot during a bulk import. Now the library has a cleaning cartridge where it expects an LTO data tape, and any backup job targeting that slot fails with 0X000010F4.

You spot this by running a full inventory report and looking for a cartridge with barcode prefix that doesn't match your data tape naming. IBM cleaners are usually CLN prefixed. Dell uses CLN too. Quantum often uses CLN or a dedicated slot number.

Fixes:

1. Move the cleaner back to the dedicated cleaner slot via the library GUI (right-click the slot, "Move Media").
2. If the cleaner slot is gone or disabled, export the cleaner to the I/O station so the robot won't try to use it.
3. Re-run the inventory.
4. In your backup software, do a media rescan so it stops treating the cleaner's old slot as a data tape.

Don't just delete the cartridge from the backup catalog. The library still sees it. Fix the physical location first, then rescan.

Cause 3: Auto-clean policy fighting manual intervention

Third cause, and the most annoying. The library has an auto-clean setting enabled ("Clean drives automatically after X hours of use" or "Clean on mount count threshold"). If someone manually inserts a cleaner at the same time, or if the cleaner's usage counter hits its max mid-cycle, the library can end up in a state where it thinks a clean is pending but the cleaner is already loaded. Hence the 0X10F4.

On IBM libraries, check Settings > Library Settings > Auto Clean. If it's on and you're managing cleans manually, turn it off. Pick one workflow — don't do both.

On Dell ML3 and similar, the auto-clean interval lives under Configuration > Library > Cleaning. Same rule applies.

Once you've disabled auto-clean, force an inventory, then power cycle the drive if the error persists. After that, verify the cleaner cartridge's usage count — most LTO cleaners are good for around 50 cleans and then they need replacing. A cleaner that's hit its limit can trigger odd errors because the drive rejects it but the robot has already placed it.

Replace the cleaner if its reported usage is at or near max. Keep a spare in the data center. They're cheap and they save you a 4-hour incident call.

Quick reference

One last thing — if you're running Veritas NetBackup or Veeam and the error keeps coming back after the library looks clean, it's the backup software's media database holding a stale record. Right-click the library in NetBackup, choose Inventory Robot. In Veeam, go to Tape Infrastructure > Libraries > Rescan. That forces a fresh read of what's actually where. Skipping this step is why people think the library is cursed when it's just a cache problem.

The 0X000010F4 code isn't scary. It's the library being honest that it found cleaning media where it expected data. Track it down physically, run an inventory, rescan from the backup app, and you're back in business.