Troubleshooting Node Management Actions
This guide covers common issues you may encounter when performing management actions on a node from the MyAccount portal — for example when an action is hidden, disabled, or rejected after you confirm it. Every action shown on a node is gated by the node's current state, the lock status, the Disaster Recovery (DR) role, the node family, and the status of any attached services. When something does not behave as expected, the table below explains where to look first.
Common Issues
| Issue | What to check |
|---|---|
| Action is disabled | Use Action Availability to check state, lock, Recovery Mode, DR role, node family, and attached-service blockers. |
| An action is rejected after it was shown | The node state or related service state may have changed after the page loaded. Refresh and retry if the action is still valid. |
| Stopped node has few actions | This is expected. Start the node before performing most management actions. |
| Reinstall or delete is blocked | Check Action Availability, especially Accidental Protection, lock status, DR role, and current node state. |
| Plan or storage change is rejected | Check Action Availability, then confirm E1 size rules or plan compatibility. |
| Bulk action skips some nodes | Review the invalid node list in the confirmation dialog; nodes can differ by state, lock, rescue, DR, family, and billing status. |
How to Read These Symptoms
Action is disabled
A greyed-out action almost always means an upstream gate is preventing it. The portal evaluates the node's state (Running, Stopped, Recovery), the lock (administrative locks), whether Recovery Mode is engaged, the node's DR role (source or target), the node family (C3, M3, E1, SDC3, WSDC4), and any attached-service blockers (snapshots in progress, scale group association, etc.). The Action Availability matrix lists every action against the gates that apply to it.
An action was shown but rejected on submit
The MyAccount page rendered the action because it was valid at the moment the page loaded. By the time you confirmed, the node state or related service state had changed — for example, a snapshot started, the node entered Recovery Mode, or an admin lock was applied. Refresh the page and retry; if the new state still permits the action, it will succeed.
Stopped node has few actions
Stopped nodes are intentionally limited to start and stop actions. This is by design: most operations require the node to be Running. Start the node and the full action set will become available again.
Reinstall or delete is blocked
The most common blocker for destructive actions is Accidental Protection. If you are confident you want to proceed, disable Accidental Protection from the node action menu first. Also verify the lock status, the DR role (DR-protected nodes cannot be deleted on the source side without breaking replication), and the current state. See Lifecycle Actions for the complete list.
Plan or storage change is rejected
Plan and storage updates have additional rules. For E1 nodes, the new root storage must fall within the supported size band (see E1 Series Troubleshooting). For plan upgrades, the target plan must be in the same category and equal or higher specs than the current plan. See Plan, Storage and Billing Actions.
Bulk action skips some nodes
When you trigger a bulk action across multiple nodes, the confirmation dialog lists which nodes are eligible and which are skipped. The eligibility check applies the same gates as a single-node action — state, lock, rescue, DR role, family, and billing status. Review the invalid node list to understand why each node was skipped and address those nodes individually.
Related Resources
- Action Availability Matrix
- Node Actions
- Network Troubleshooting
- Security Troubleshooting
- E1 Series Troubleshooting