Critical Data Loss: Reseller deletion causes silent cascading removal of users without warning

[bitpt]

Hi everyone,


I’m writing to report a critical issue (and a warning to others) regarding how DirectAdmin handles User/Reseller relationships during deletion, which led to a catastrophic data loss in my environment.

The Scenario:I recently migrated several accounts from cPanel to DirectAdmin. After the migration, I faced some inconsistencies:

• Some Users became "orphans" (they existed on the disk but weren't showing up correctly in the GUI).
• Resellers didn't have their Users correctly allocated in the interface.
• I tried to manually fix the user.conf, user.list, and reseller.list files, but the GUI still wouldn't sync properly.
• da taskq --run="action=cache&value=showallusers" etc etc

The Issue:In an attempt to "reset" the Reseller structure, I decided to delete the Reseller account and recreate it, assuming that since the Users weren't appearing under that Reseller in the GUI, they wouldn't be affected.

The Disaster:To my absolute shock, DirectAdmin performed a complete cascading deletion. Even though the Users were not visible in the Reseller's list in the GUI, the system identified the relationship in the backend and wiped everything:

• /home/user directories (completely gone).
• DNS Zones.
• Databases.
• Most critically: All Email accounts and data (one account had over 200 mailboxes). Hundreds of emails gone from today and yesterday.

The Suggestion:There was not a single warning stating that "The following Users will also be deleted". If a User is not explicitly listed as a child of a Reseller in the interface, the admin should be prompted or warned before a background wipe occurs.

This behavior is extremely dangerous during migrations or when troubleshooting "orphan" accounts. I strongly suggest that the DA team implements a mandatory confirmation list or a "Move Users to Admin" safety check before allowing a Reseller deletion to proceed with a full data wipe.

Has anyone else experienced this? Is there any way to prevent the binary from executing user_destroy.sh during a Reseller removal if the Users are in an inconsistent state?

Happy new year to you all!

 

[bitpt]

Following my recent experience with a massive data loss (200GB +15users 610 emails in exim log), I would like to propose a fundamental change in how DirectAdmin manages User/Reseller relationships.

The Issue with the Current Architecture: The current reliance on flat-files (.list and .conf) for defining hierarchies is prone to desynchronization. If a user is not correctly indexed in the Reseller's text file (due to a migration glitch or manual edit), they become "invisible" to the GUI but remain "linked" to the deletion binary. This led to a silent cascading deletion of accounts that I couldn't even see in the interface.

My Suggestion: DirectAdmin needs a more robust, possibly database-driven, integrity check for user management.

Relational Integrity: The system should not allow a Reseller to be deleted if there are child accounts still linked in the backend. This relationship should be validated by a core database/indexing service, not just by reading a text file.

Cascading Protection: Any "cascade delete" operation must be preceded by a mandatory system-wide scan that lists every affected directory, database, and email account. If the system finds "orphan" users linked to that Reseller, it must stop the process and require manual intervention or a "Move to Admin" action.

Modernizing the Backend: Relying on manual cache rebuilds to sync the GUI with the disk is a legacy approach that carries too much risk. A 200GB loss happened because the "reality" of the disk was different from the "reality" of the GUI files.

In short: User management should be handled by a more robust, atomic system that prevents any destructive command from executing if there's an inconsistency in the account mapping.