Based on the NetApp Knowledge Base record for CONTAP-697033. The linked Google News record preserves the official headline but did not expose the KB article body during verification.
Amazon FSx for NetApp ONTAP HA takeover CONTAP-697033 2026-10-28What NetApp identified
CONTAP-697033 describes a specific Amazon FSx for NetApp ONTAP failure chain: a transient disk error is followed by partner disks appearing to be missing, and takeover is blocked. The record is about the high-availability transition, not a general announcement that every transient disk event causes data loss or that all FSx for ONTAP file systems are affected.
The public headline supplies no affected ONTAP release, patch level, AWS Region, file-system generation, fix version, workaround or recovery procedure. It also does not state whether the condition is automatically cleared or requires intervention. Those omissions matter: they prevent a responsible version matrix or command-level runbook from being derived from the headline alone.
Why a blocked takeover matters
Takeover is the HA action that lets one node assume its partner’s storage service. If takeover is blocked during the condition described here, the expected failover path is not available at that moment. That narrows the operational claim: the issue is loss of takeover readiness after the stated disk-error sequence. The headline does not establish that client I/O has already stopped, nor does it quantify an outage duration.
For the surrounding architecture and responsibility boundaries, see the FSx for ONTAP reference. For the ONTAP concepts behind ownership, partner visibility and disk state, see RAID and disks. Those references explain the model; they are not a workaround for CONTAP-697033.
What customers should do with this signal
FSx for ONTAP operators should treat a transient disk error followed by missing-partner-disk indications and a blocked takeover as a recognizable incident signature. Preserve the event timeline and the exact messages shown by the managed service, and use the AWS support path for the affected file system. Because this is a managed service and no verified corrective command is present in the accessible source, this article intentionally does not prescribe ONTAP CLI changes.
Do not turn the headline into a fleet-wide upgrade recommendation. Without an affected-version field and a fixed-version field, there is no evidence-based release target to name. Likewise, there is no published basis here for forcing takeover or changing disk ownership.
ONTAP, StorageGRID and BlueXP scope
The named product is Amazon FSx for NetApp ONTAP. The mechanism uses ONTAP HA and disk terminology, but the record does not say that customer-managed ONTAP clusters are affected. It names neither StorageGRID nor BlueXP, so no direct StorageGRID or BlueXP product change can be claimed from this source. BlueXP users who manage or observe the affected FSx environment may see the operational consequence, but that is an integration context, not evidence of a BlueXP defect.
What to watch next
The useful next publication would add the fields missing from the syndicated record: affected and fixed ONTAP versions, the precise event or alert signature, recurrence conditions, service-restoration steps, and whether AWS performs any remediation automatically. Until NetApp or AWS publishes those details, the defensible conclusion is limited to the documented sequence and blocked-takeover symptom.
Source: NetApp Knowledge Base / Google News record, CONTAP-697033 (syndicated October 27, 2026). No press release was found for this support issue; it is covered as a KB incident record, not recast as a corporate announcement.