Storage Admin Hub
All guides/Troubleshooting
Troubleshooting · Worked procedure

LUN missing or paths degraded

Find the first broken link from HBA to LUN map.

By Hrishikesh NaikUpdated 4 min read
Scope

SCSI FC/iSCSI paths · preserve identity and surviving I/O

Scenario

Example: a host sees only one of four expected paths after switch maintenance. Preserve the surviving path while diagnosing the missing fabric.

About the command and output examples

Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.

01Confirm impact and identity

  1. Record host, IQN/WWPN, LUN serial, LUN ID, SVM, protocol, affected fabric, and time. Check whether I/O is still running and whether multipath is protecting the workload.
  2. On ONTAP, confirm LUN online and mapped to the intended igroup. Compare host initiator ID exactly.
Read-only checks 
lun show
lun mapping show
network interface show
storage failover show

02Walk the path

  1. For iSCSI: check host NIC/VLAN/MTU and route, TCP portal reachability, target service, discovery/session login, igroup IQN, then multipath.
  2. For FC: check HBA and switch port link, active zone set, target WWPN login, FC LIF state, igroup WWPN, host rescan, then multipath.
  3. Inspect one failed path at a time. Do not change a healthy fabric during an active outage unless the plan requires it.
Acceptance check

The missing path is identified at a specific layer, such as switch zoning or initiator mapping.

03Restore and validate

  1. Apply the narrow fix through change control. Rescan the host and verify expected path count, path states, device serial, and I/O latency.
  2. If any device appears duplicated, stop before formatting or mounting. Verify serial and multipath aggregation.
Acceptance check

All planned paths restored and stable; host logs show no new I/O errors.

04Worked outage: Fabric B is absent, Fabric A remains healthy

Start with the host device’s stable identifier, not a path device name that may change across reboots. Record which adapters and target WWPNs/portals belonged to the missing paths. A LUN mapping that works through Fabric A is useful evidence: changing it globally while investigating Fabric B can remove the surviving access.

Walk the failed path without changing the healthy fabric
StageFabric B evidenceNext check
Host adapterLink down / no sessionsHBA/NIC, driver, optic/cable and port
Fabric connectivityInitiator logged in; target missingTarget port/LIF and active fabric login
AuthorizationBoth endpoints present; no mapped deviceActive zoning or iSCSI auth, then igroup/mapping
Host aggregationRaw paths present but not in multipathSupported host configuration and device identity
  1. Compare the affected host with another host using the same switch or target, and compare B with A. Use the pattern to identify a shared component.
  2. For FC, verify the active configuration rather than only a saved zone database. For iSCSI, separate portal discovery from authenticated session login.
  3. After the narrow fix, rescan using the supported host process and confirm the same LUN identity, restored paths and application I/O.

05An identity mismatch changes the incident response

If maintenance makes a device look new or duplicate, stop before formatting, importing a filesystem or mounting a second copy. Compare LUN serial, WWID/NAA, mapping, datastore/filesystem identity and DR history. A path problem is not a reason to recreate a LUN. Preserve the original mappings and obtain a storage/host recovery decision for any identity conflict.

Acceptance check

Closure records the specific failed path/component, original and recovered device identity, restored path coverage and application test.

06Worked case: one fabric path disappears after maintenance

Fictional investigation. A host still sees its LUN but has two paths instead of the four recorded before maintenance. The application is still serving I/O. Start by recording the LUN identity and preserving the surviving fabric; do not recreate a LUN that is already visible.

Trace the first point where expected evidence is missing
LayerExample observationDecision
Host multipathSame LUN identity; two Fabric A paths remainKeep Fabric A untouched
Fabric B loginHost initiator is logged in; expected target is absentTrace the target-facing connection before changing zoning
Target-facing switch portPort is down after cabling workVerify cable labels and target port against the change record
After approved cable correctionTarget logs in and host paths recover to fourVerify application I/O and stable path counts
  1. Use the pre-change path inventory to map lost paths to a specific fabric and target. Check that the target is expected to log in on that switch.
  2. Compare target-facing link status and logins before reviewing effective zoning or ONTAP LUN mapping. A target that is not logged in needs a link/login investigation first.
  3. Have the authorized operator correct the identified Fabric B connection. Recheck the target login, expected paths and application I/O; avoid touching the healthy fabric.
Acceptance check

The original LUN identity is unchanged, the expected paths return, and the application remains healthy during the observation window.

Continue learning

Use the section links to revisit a step, or follow a related guide below.

Official references and further reading

Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.