When attempting to mount a datastore to an ESXi host, the volume may fail to mount automatically. This typically occurs during disaster recovery tests, after a ransomware recovery, replacing a local storage controller, or when a snapshot/replica LUN is presented. This mismatch between the LUN's current characteristics (such as NAA ID) and the recorded metadata signature prevents the host from mounting the volume to avoid metadata conflicts. This is critical when the affected datastore contains essential virtual machines, such as a vCenter Server, that must be restored.
'An unresolved VMFS volume with signature naa.#### has been detected on disk'./vmfs/volumes directory during an SSH session.Log in to the ESXi host via SSH and run: esxcfg-volume -l
VMFS UUID/label: ##-##-##/####Can mount: No (duplicate extents found)Can resignature: No (duplicate extents found)Extent name: naa.####:1 range: 0 - 4194047 (MB)Extent name: naa.##:1 range: 0 - 4194047 (MB)ESXi detects a signature mismatch or duplicate extents, triggering signature protection.
esxcfg-volume -lesxcli storage vmfs snapshot resignature -u "########-########-####-############"snap-XXXX-..vmx file for the vCenter Server or lost VM..vmx file to the inventory.