Multipath IO device path down

Multipath IO: device path down – fix in 3 steps

Hardware – Hard Drives Intermediate 👁 7 views 📅 Jun 29, 2026

One or more paths to your SAN storage show as down. We'll walk from a quick restart to rebuilding the multipath config. No fluff.

Multipath IO device path down – what you're seeing

You run multipath -ll and see 'path down' or 'failed' on one or more paths to your SAN storage. Your apps might still run, but performance drops. I've seen this on RHEL 7, 8, and Ubuntu 18.04. Usually happens after a fiber cable was unplugged or a switch rebooted.

Fix #1: restart multipathd (30 seconds)

This is the easiest thing. Multipathd sometimes gets confused and doesn't recheck paths fast enough. On Red Hat or CentOS:

systemctl restart multipathd

On older systems:

service multipathd restart

After restart, run multipath -ll again. If the paths show 'active' now, you're done. If not, move on.

Fix #2: check cables and switches (5 minutes)

If restart didn't fix it, something physical is wrong. Check the fiber cables to both the HBA and the switch. I had a client last month whose cat chewed through a patch cable. Real thing.

Check the switch logs. On a Brocade switch:

portlogshow

Look for 'Link Failure' or 'Loss of Signal'. If you see those, swap the cable. Also check the SFP modules – I've seen bad SFPs that look fine but drop paths randomly.

Fix #3: rebuild multipath.conf (15+ minutes)

If cables are good and restart didn't help, your multipath configuration is probably wrong. Common issues: missing aliases, wrong path checker, or no device settings for your specific SAN.

Start by backing up the current config:

cp /etc/multipath.conf /etc/multipath.conf.backup

Then look at the default config. On most systems, you can generate a fresh one:

mpathconf --enable --user_friendly_names n

But that's generic. For a specific SAN like a Dell EqualLogic or NetApp, you need proper device settings. Here's a working example for an EqualLogic SAN:

defaults {
    user_friendly_names no
    path_grouping_policy multibus
    path_checker tur
    prio_callout /sbin/mpath_prio_alua
    rr_min_io 100
}

devices {
    device {
        vendor "Dell"
        product "EqualLogic*"
        path_grouping_policy multibus
        path_checker tur
        prio_callout /sbin/mpath_prio_alua
        rr_min_io 100
        features "0"
        no_path_retry 5
    }
}

After editing the config, reload multipathd:

multipath -F
systemctl reload multipathd
multipath -v2

Then check multipath -ll again. If you still see down paths, check the system logs:

journalctl -u multipathd

Look for 'path checker' errors. Those tell you what's failing.

Final check: hardware issues

If none of these fix it, you might have a dead HBA port or a bad disk in the SAN. Check your storage array's management interface for alerts. I had one client where an entire disk shelf lost power, and multipath correctly showed all paths down. That's not a multipath problem – that's a storage problem.

Also check that your HBAs see the target LUNs:

lsscsi

If the LUNs aren't listed, it's not a multipath issue – it's a zoning or cabling issue at the SAN level.

When to call someone

If you've done all three fixes and still see down paths, and you're sure cables and switches are fine, call your storage vendor or a consultant. You might need to rezone the SAN or update firmware. Don't waste a full day on this – I've seen teams spend a week before calling a specialist.

Was this solution helpful?