Multipath IO: device path down – fix in 3 steps
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?