Where reseller ACLs are stored in WHM: technical analysis, source of truth, and production troubleshooting

In cPanel/WHM operations, reseller privilege control is a security-critical layer. The issue is that the interface does not always reflect backend persistence immediately or consistently.

This article documents a real case where a named ACL created in the GUI did not persist, plus the exact diagnostic and hardening flow I used to stabilize ACL lifecycle management in production.

1) ACL model in WHM

WHM works with two practical ACL modes:

• ad hoc ACLs attached directly to a reseller account;
• named ACL templates reused across multiple resellers.

Permissions cover operational actions such as account creation, DNS management, SSL actions, quotas, and related capabilities.

2) Source of truth on disk

The central file for reseller ACL state is:

/var/cpanel/resellers

Direct check:

cat /var/cpanel/resellers

If the expected ACL does not appear there, backend persistence is incomplete.

3) Observed failure pattern

Real sequence:

1. ACL was created in Edit Reseller Nameservers and Privileges.
2. ACL template name was entered.
3. UI showed partial success feedback.
4. After refresh, ACL was missing for reuse.

Backend inspection confirmed the ACL template was not committed in /var/cpanel/resellers.

4) Most common operational root cause

Incomplete GUI commit flow. Typical triggers:

• naming a new ACL but not finishing with the final global save action;
• interrupted page refresh/session timing issues;
• UI state saved partially while backend entry is not fully materialized.

Net effect: apparent success in UI, missing source-of-truth state.

5) Senior-level SSH checklist

5.1 API state

whmapi1 listacls --output=jsonpretty

If missing here, ACL is not reliably available.

5.2 Raw lookup under cPanel paths

grep -R "acl_name_here" /var/cpanel/

Useful for identifying partial writes or stale references.

5.3 File integrity and ownership

ls -l /var/cpanel/resellers
stat /var/cpanel/resellers

Confirm root ownership and expected permission mode for your baseline.

6) Safe GUI flow (if GUI is required)

Reliable sequence:

1. Select all intended ACL permissions.
2. Enter new ACL template name.
3. Click Save All Settings at the end of the page.
4. Wait for full refresh.
5. Revalidate with API + file checks.

Without post-save validation, you are trusting UI state only.

7) Production-recommended method: WHM API 1

For deterministic behavior, I standardized ACL creation with API:

whmapi1 saveacllist \
  acllist=jvx_n1 \
  acl-list-accts=1 \
  acl-park-dns=1 \
  acl-ssl=1 \
  acl-wp-toolkit=1

Apply template to reseller:

whmapi1 setacls reseller=example_reseller acllist=jvx_n1

This avoids GUI sync edge cases and improves repeatability.

8) Mandatory post-change validation

whmapi1 listacls --output=jsonpretty
whmapi1 listresellers --output=jsonpretty
grep -R "jvx_n1" /var/cpanel/resellers

Then validate effective behavior in reseller session:

• restricted menus are not exposed;
• allowed operations execute successfully.

9) Security and operational best practices

9.1 Backup before changes

cp -p /var/cpanel/resellers /var/cpanel/resellers.$(date +%F-%H%M%S).bak

9.2 Avoid manual direct edits

Manual edits can break syntax or introduce collateral permission issues across reseller entries.

9.3 Treat ACLs as operational code

• keep named ACL catalog documented;
• version API commands (saveacllist) in internal repo;
• enforce post-change verification runbook.

9.4 Keep audit trail

Track who changed ACLs, when, and why. This materially reduces MTTR during permission-related incidents.

10) Fast incident runbook for “ghost ACL”

# 1) check ACL existence via API
whmapi1 listacls --output=jsonpretty | grep -i "jvx_n1"

# 2) confirm source-of-truth file state
grep -R "jvx_n1" /var/cpanel/resellers

# 3) recreate ACL template by API
whmapi1 saveacllist acllist=jvx_n1 acl-list-accts=1 acl-park-dns=1 acl-ssl=1 acl-wp-toolkit=1

# 4) reapply to reseller
whmapi1 setacls reseller=example_reseller acllist=jvx_n1

# 5) validate again
whmapi1 listacls --output=jsonpretty | grep -i "jvx_n1"

Technical conclusion

When an ACL “disappears” in WHM, the most common issue is incomplete GUI persistence, not missing backend capability.

Treat /var/cpanel/resellers as source of truth and standardize on saveacllist/setacls via WHM API for production-grade reliability, auditability, and controlled access governance.

This post is licensed under CC BY-NC.