ONTAP Giveback Vetoed by lock_manager: Non-CA SMB Locks

Scope and symptom

The source applies to ONTAP9, ONTAP Select and Cloud Volumes ONTAP serving SMB/CIFS shares without continuous availability (CA). After a reboot, an aggregate can remain on its partner rather than returning home, leaving partial giveback.

Archived status examples

::>storage failover show
Takeover
Node       Partner     Possible State Description
-------------- -------------- -------- -------------------------------------
node1       node2       true    Connected to node2
node2       node1       true    Connected to node1, Giveback of
                             one or more SFO aggregates failed
2 entries were displayed.

::>storage failover show-giveback
Partner
Node           Aggregate         Giveback Status
-------------- ----------------- ---------------------------------------------
node1
                                 No aggregates to give back
node2
               CFO Aggregates    Done
               aggr_node1        Failed: Operation was vetoed by
                                 lock_manager. Giveback failed during lock
                                 manager veto checks or the pre-commit phase.
                                 For veto failures, use the "vserver cifs
                                 session file show -hosting-aggregate
                                 <aggregate list> -continously-available No"
                                 command to view the open files that have
                                 CIFS sessions with non-CA locks established.
                                 <aggregate list> is the list of aggregates
                                 sent home as a result of the giveback
                                 operation. If lock state disruption for all
                                 existing non-CA locks is acceptable, retry
                                 the giveback operation by specifying
                                 "-override-vetoes true". Warning: Overriding
                                 vetoes to perform a giveback can be
                                 disruptive. For pre-commit failure, search
                                 for the lmgr.precommit.oplock.recall EMS
                                 variant for information on how to proceed
                                 using the "event log show -event
                                 lmgr.precommit.oplock.recall.*" command. If
                                 the error persists, contact technical
                                 support for assistance.
2 entries were displayed.

The raw message above contains the source spelling -continously-available. For an actual query, the documented parameter is -continuously-available:

vserver cifs session file show -hosting-aggregate <AGGREGATE_LIST> -continuously-available No
event log show -event lmgr.precommit.oplock.recall.*

Other source indicators

[node2: cf_giveback: gb.sfo.veto.lmgr.nonCA.locks:error]: Could not complete giveback because of non-CA locks on volume vol_node1@vserver:123a-123a-123a-123a-123a-1234567890ab SFO aggregate aggr_node1.
[node2: cf_giveback: sfo.sendhome.subsystemAbort:alert]: The giveback operation of 'aggr_DATA' was aborted by 'lock_manager'.
[node2: cf_giveback: ha.giveback.totalVetoChk:debug]: Total time taken to check whether to veto the giveback of aggregate 'aggr_DATA' was 5 msecs.

BlueXP/Cloud Manager (now named differently in newer vendor material) can show Working Environment is degraded, a non-highly-available state or incomplete node giveback. System Manager can report:

Failed to initiate giveback. Run the "storage failover show-giveback" command for more information.
Degraded - Show Details
HA cluster is not highly available.The node giveback was not completed.

The source’s volume/aggregate names and lock IDs are examples. Inspect the actual veto/precommit events rather than assuming every failed giveback is caused by non-CA locks.

Cause in this case

Active SMB sessions still have open files/non-CA locks on volumes in the aggregate. Their lock state cannot be preserved across the relevant relocation in the same way as a supported continuously available workflow.

Choose the appropriate giveback option

1. Coordinate application closure: gracefully close the SMB applications holding files, or schedule a quieter access window, then retry normal storage failover giveback.
2. Move the affected volume: the source alternatively moves volumes with open files to another suitable aggregate, then performs normal giveback. Validate capacity, topology and supported volume-move behavior for the actual configuration; a move is not automatically appropriate or nondisruptive for every workload.
3. Override only after accepting lock disruption: overriding the veto loses existing non-CA SMB lock state and can interrupt shares or cause data loss. If that impact is acceptable under the coordinated maintenance procedure, the source uses:

storage failover giveback -ofnode <NODE_NAME> -override-vetoes true

The source notes that each aggregate resumes its home-side I/O as its giveback completes; this does not remove the SMB lock-disruption risk. Confirm final HA/aggregate health and application reconnection after the chosen procedure. For precommit/oplock-recall failures or unresolved errors, use the specific event details and vendor support rather than repeatedly forcing giveback.

Reference: matching official English lock_manager case. The public page confirms the symptom pattern; do not assume access to any gated full solution.