SAN LUN Disappears: 3 Causes & Fixes

1. Zoning or Masking Changed (Most Common)

What's actually happening here: somebody changed the SAN zone config or LUN masking on the storage array. Maybe a co-worker was cleaning up “unused” zones and removed your server's WWPN. Or a new firmware update on the switch reset the zone set. The host OS still sees the HBA, but the LUN never comes back — it's not just missing, it's completely gone from fdisk -l or Disk Management.

Real-world trigger

A storage admin re-zoned a Brocade switch during maintenance, but forgot to enable the zone config. The server's HBA lights stayed green, but the LUN vanished.

How to confirm

1. On the host, run lsscsi (Linux) or check Device Manager for “unknown” devices (Windows). If you see the HBA but no LUNs, it's likely zoning.
2. Check the SAN switch for the host WWPN in the active zone config.
3. On the storage array, verify LUN masking includes the host's WWPN or iSCSI IQN.

Fix

Re-zone or re-mask properly. Use the storage array's management GUI to confirm the host is mapped to the correct LUN. On the switch, run cfgshow (Brocade) or show zone (Cisco MDS) and enable the config. Then rescan on the host:

# Linux: echo "- - -" > /sys/class/scsi_host/host*/scan
# ESXi: esxcli storage core adapter rescan --all
# Windows: use diskpart -> rescan

The reason step 3 works: rescan tells the OS to re-query the fabric. If zoning is correct, the LUN pops back immediately.

2. Multipath Timeout or Failover Issue

Less common but trickier: the LUN is still zoned and masked, but your multipath software lost its mind. What's actually happening: one path to the storage controller goes down (cable pull, HBA failure, switch port flaky), and the multipath daemon (like multipathd on Linux or MPIO on Windows) doesn't fail over properly. The LUN shows up in multipath -ll but status is “faulty” or “timeout”.

Real-world trigger

A server with two HBAs connected to two separate switches. One switch had a spanning-tree loop that flapped the port. The multipath daemon marked the path as “failed” but never switched to the good path because of a stale persistent reservation.

How to confirm

• Linux: multipath -ll — look for “faulty” or “timeout” on one or more paths. Also dmesg | tail -50 shows SCSI errors like ABORTED COMMAND or UNIT ATTENTION.
• Windows: check MPIO tab in disk properties. If it shows “inactive” or “standby” and you can't read/write, that's your problem.

Fix

First, check physical connections — reseat cables or replace the suspect HBA. Then force a multipath reconfigure:

# Linux: multipath -r && systemctl restart multipathd
# Windows: mpclaim -r -i (then reboot)

If that doesn't work, check the path policy. For ALUA arrays, set it to round-robin or group_by_prio. Non-ALUA arrays need failover. Wrong policy = LUN stuck on a dead controller.

3. Storage Controller Failover (Active/Passive)

This one hits when the storage array has two controllers and one dies or gets firmware upgraded. On an active/passive array (like older EMC VNX, Dell PowerVault MD series), the LUN's owner controller fails over to the standby. But the host's SCSI reservation or ALUA path selector doesn't switch, so the LUN goes read-only or disappears.

Real-world trigger

A scheduled firmware upgrade on a Dell MD3200 storage array caused controller A to reboot. The LUNs owned by controller A failed over to controller B. The Windows server had MPIO with a “failover only” policy, but the LUN's active path was to controller A (now offline). MPIO didn't switch because the path policy was set wrong.

How to confirm

• Check the storage array's event logs for controller failover events.
• On the host, look at the LUN's active controller. Linux: multipath -ll shows “active” vs “standby”.
• On Windows, check “MPIO Disk” > “Details” tab for active path.

Fix

If the LUN is read-only or offline, manually change the active path:

# Linux: multipath -u /dev/mapper/mpathX
multipath -t mpathX -p 1 (switch to path 1)

# Windows (diskpart):
select disk X
attributes disk clear readonly
online disk

For the long term, fix the path policy. On active/passive arrays, set MPIO to “failover only” on Linux (path_grouping_policy failover) and “failover only” on Windows. On active/active arrays, use “round-robin”.