FortiGate VDOM Deletion Blocked? A Complete Troubleshooting Guide to References, Hidden Configs, and CLI Solutions
.
For network administrators managing FortiGate firewalls in multi-tenant or segmented environments, Virtual Domains (VDOMs) are essential. However, deleting a VDOM often fails despite an administrator’s belief that all associated objects are gone.
The core issue is universal: FortiOS employs strict referential integrity. A VDOM cannot be deleted if any configuration object—visible or hidden—still references it. This report compiles official Fortinet troubleshooting tips and expert workarounds to systematically identify and remove these persistent dependencies.
Primary Causes—Why Won’t It Delete?
Analysis of official Fortinet documentation reveals four primary categories of deletion blockers:
1. Direct Object References
The most common blockers include:
- Network Interfaces assigned to the target VDOM.
- Firewall Policies or Static Routes utilizing interfaces within that VDOM.
- Administrator Accounts explicitly granted access to the VDOM.
2. Invisible or "Built-in" Interfaces (Safe to Ignore)
Every VDOM automatically creates virtual interfaces. Crucially, these do NOT block deletion:
ssl.<vdom>(SSL VPN)naf.<vdom>(NAT46/NAT64, v7.0+)l2t.<vdom>(L2TP, v7.0+)npu0_vlink1.<vdom>(NPU offload)
Do not waste time trying to delete these; they are removed automatically with the VDOM.
3. Administrative Account Binding
A very frequent blocker is the super-admin account itself. If the admin account used to delete the VDOM is still "logged in" to that VDOM, deletion fails. The VDOM appears in the config system admin list.
4. The "Hidden Config" – GUI Dashboard Entries
A critical 2024 Fortinet KB article (TA-326666) identifies a stealth blocker: GUI dashboard configurations. When an administrator logs into a VDOM, a hidden gui-dashboard entry is created under the admin account. This entry is not visible via standard show or show full-configuration commands, yet it registers as a reference and greys out the delete button.
The Diagnostic Toolkit – Locating the Dependency
Before deletion, precise identification is required. Fortinet provides a powerful diagnostic command that supersedes guesswork.
The "Refcnt" Command (Reference Count)
Run this command from the Global VDOM:
diagnose sys cmdb refcnt show system.vdom.name <VDOM_NAME> Expected Output & Interpretation:
| Output Line | Meaning | Action Required |
|---|---|---|
used by table system.interface:name | Physical/VLAN/Loopback interface in VDOM | Move interface to another VDOM (e.g., root) |
used by child table ... system.admin:name | Admin account has VDOM access | Remove VDOM from admin profile |
used by table system.vdom-property:name | Standard VDOM property | Normal, will clear when others are fixed |
used in table system.interface ... 'npu0_vlink1' | NPU offload interface | Ignore (auto-deleted) |
Important: If the command returns no output but the GUI still shows "References", suspect the Hidden GUI Config.
Step-by-Step Remediation
Phase A: Cleaning Standard References (GUI & CLI)
1. Interfaces & Policies
- GUI:
Global > Network > Interfaces. Check the "VDOM" column. Move any interface assigned to the target VDOM toroot. - If dropdown is greyed out: The interface is used in a policy/route. Delete those dependencies first using the "Ref." column in the GUI.
2. Administrator Access
- CLI:
config system admin edit <admin_name> set vdom root # Removes the target VDOM from the list end end
Phase B: The "Hidden Config" Removal (Critical Step)
If standard checks pass but the VDOM remains undeletable, the issue is likely the invisible GUI dashboard.
Procedure:
- Identify the offending admin. (Usually the one used to log into the VDOM).
- Manually delete the GUI dashboard entry via CLI:
config system admin edit <admin_name> config gui-dashboard # Delete the specific entry referencing the VDOM delete <entry_id> end end - Verify: Run the
refcntcommand again. The admin reference should be gone.
Phase C: Final Deletion
Once all references are cleared:
CLI Command:
config vdom delete <VDOM_NAME> end GUI: Navigate to System > VDOM. The "Delete" button will be active.
Special Considerations & Common Pitfalls
| Scenario | Constraint | Solution |
|---|---|---|
| Root VDOM | Cannot be deleted. | This is the default management domain. |
| Management VDOM | Cannot be deleted. | The VDOM designated for management access. |
| Disabled VDOM | Cannot be deleted. | You must first enable the VDOM (set status enable) before deletion. |
| HA Cluster | Vcluster inconsistency. | Ensure the VDOM is active on the same cluster member as the management VDOM. |
| Misspelled VDOMs | CLI typo creates unintended VDOM. | Check VDOM list periodically; treat as standard VDOM for deletion. |
FAQ: FortiGate VDOM Deletion
I moved all interfaces out, but the VDOM still won't delete. What now?
Check diagnose sys cmdb refcnt show system.vdom.name <vdom>. If only system.admin references remain, remove the VDOM from the administrator profile. If the command shows nothing, perform the "Hidden GUI Dashboard" cleanup under config system admin.
Can I delete a VDOM if it has the built-in interfaces like ssl.<vdom>?
Yes. These virtual interfaces are created automatically and do not block deletion. They will be removed when the VDOM is deleted. Focus on moving physical/VLAN interfaces.
Why is the "Delete" button greyed out even when the Reference column shows 0?
This is a classic symptom of the hidden gui-dashboard configuration. You must delete the dashboard entry via CLI as it is not visible in the standard configuration output.
Does disabling a VDOM help me delete it?
No. A disabled VDOM cannot be deleted. You must enable it first, then remove all references.
I created a VDOM with a typo and cannot edit the name. How do I remove it?
You cannot rename a VDOM. You must delete it using the standard procedure (clear references, then config vdom; delete <wrong_name>). This is a strict FortiOS limitation.
Is there a wildcard command to remove all references at once?
No. FortiOS does not support mass-removal of references for safety reasons. Each dependency must be removed manually or via scripting specific object paths.
Always test commands in a maintenance window or lab environment first.