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

B

bitpt

New member
Joined
Dec 15, 2025
Messages
10
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!
 
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.
 
Thanks for your reply. I have already carefully reviewed the documentation regarding orphaned users, but the standard commands are not resolving the issue. Here is the current status and the failures I'm encountering:

1. Inconsistent Reseller State
The main Reseller account are missing from the Reseller list in the GUI/CLI, even though:

The login works perfectly.
All sub-accounts (users) belonging to these 2 specific resellers are visible and functional.
The Reseller account itself seems "invisible" to the system's management layer.

2. Move Script Failure
I tried to use the move_user_to_reseller.sh script (or the GUI equivalent) to re-assign or "fix" the ownership, but it fails because:

The target account(main reseller account) does not appear in the list of available users.

The system claims the account does not exist or is not a valid destination.

3. Manual user.conf Modifications
I attempted to manually fix the mapping in /usr/local/directadmin/data/users/[user]/user.conf by verifying the creator and reseller fields.

Even after updating these files and running ./dataskq d2000, the changes are not reflected in the DirectAdmin interface.

The link between the filesystem configs and the live environment seems broken for these specific accounts.

Current Question: Since the standard "orphaned users" documentation assumes the Reseller is active and only the User is lost, how should I proceed when the Reseller account itself is the one that is orphaned/invisible to the system, despite having a valid home directory and config files?

Is there a way to force a cache rebuild of the reseller.list or a specific task queue command to re-register these main accounts (without delete everything)?

Happy New Year!
 
You might try to check these for visibility in the GUI. I know you already done a lot of this, just doublechecking.

1.) check the /usr/local/directadmin/data/users/accountname/user.conf file where you change accountname to the reseller accoutname.
In the user.conf of the reseller, check if these are present and set:

Fairly on top of the file, this entry should be present.
creator=admin
If creator is not admin but another entry in your case, please display here.

Somewhere in the middel check for presence of a:
package=xxxx
entry where the xxxx is the packagename for the reseller. Please take care you have already created reseller packages before making changes.

On the bottom of the file, below the username this should be present:
usertype=reseller

I've read you did updated that, but after that you ran the task queue. Have you also tried restarting the directadmin service?
Might be the same but just to be sure:
service restart directadmin
best done from CLI so if there are errors you can see which errors.

Also, check this file again:
/usr/local/directadmin/data/admin/reseller.list
should only contain the username, nothing more. Probably you checked, just mention it to be sure.

2.) That is not a move script failure. That script is intended to move users between resellers, not to upgrade a user to a reseller.

3.) Is related to 1 imho.

Probably this will a bit difficult due to the old/new years day, but hopefully maybe @romans can help you or if you're on a modern full license you could send in a ticket.
 
Terrible shock of course, but restoring the backup doesn't work either? I mean, you could retry to solve the display issue again and not delete the reseller but create a new one or rename the old one and recreate it under the 'old' name?

I don't think this is a DA-issue but behavior that is by design. I second sufiyanshaikh's suggestion.
 
bitpt said:
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.
Click to expand...

Actually when using the web-interface of DirectAdmin for removing of an admin/reseller account there is a warning in the evolution skin. Kindly see the attached image:

poralix.png


Historically directadmin allows a removal of admin/resellers with users. It might require much changes to be done in unknown amount of software and applications that use DirectAdmin API if they change the behaviour.
 
Sorry Zeiter ..
I just checked and I don't see that window in my panel. It really shouldn't be this hard to secure these settings, system shouldn't rely only on flat files. I'll dig into this more in the coming days. So far, the only problems I've run into with DA involve the user structure.

Yes i have a full licence. i'm new in DA. But first i try what possible do before tickects i'm new in DA but not so new in server admin.

I had backups from two days ago, but I've lost 600 emails from a client and need 200GB restore of lost data.

Richard i do it all, always back to admin and miss user in reseller
I’ve tried everything. The user always reverts to the Admin account and goes missing from the Reseller. Even after manually editing user.conf and other files, as soon as I restart DirectAdmin, the user is moved back to 'Admin' and disappears from the Reseller’s GUI. The server is in production, and all users are there and working, but some are simply missing from the GUI. Reseller login OK, only miss your own account.

I will look in next days. Now, it's time to celebrate.

A Happy New Year to you all, and thanks for your help!
 
Just to clarify ... yes that appear
But not all time and in all conditions.. try import some users from a cpmove users allocated to a reseller backups without packages... no warning. I'll see in the next days.. thank you

1767205852624.png


No warning if is a orphan user, but delete even orphan .... try it pls
 
You must log in or register to reply here.
Back
Top