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.

 

[Active8]

Maybe this can help to rebuild your users/resellers

Maintaining domains, users, resellers | Directadmin Docs

DirectAdmin Knowledge Base

docs.directadmin.com

 

[bitpt]

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!

 

[Richard G]

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.

 

[sufiyanshaikh]

Why don't you open a support ticket with DA?

 

[brinkie]

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.

 

[Richard G]

I second sufiyanshaikh's suggestion.

Which I also already suggested in my last line. But he might not have the correct license for ticket support.

 

[zEitEr]

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.

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:

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.

 

[bitpt]

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!

 

[zEitEr]

Sorry Zeiter ..
I just checked and I don't see that window in my panel

I get in on Dashboard -> List Administrators -> Delete

 

[bitpt]

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

No warning if is a orphan user, but delete even orphan .... try it pls

 

[zEitEr]

No warning if is a orphan user, but delete even orphan .... try it pls

If under orphan users you mean users, which are not listed in any admin's or reseller's users.list file, then it's expected, you don't see the warning. I understand that you are worried about users that might be missing in the file users.list. But if a user is missing in the users.list why would it be deleted on a admin/reseller removal?

 

[Zhenmue]

you should create the ticket.

that way, DA can reproduce the issue, and fix it if there is any.

 

[bitpt]

If under orphan users you mean users, which are not listed in any admin's or reseller's users.list file, then it's expected, you don't see the warning. I understand that you are worried about users that might be missing in the file users.list. But if a user is missing in the users.list why would it be deleted on a admin/reseller removal?

In system design, destructive actions, especially those with cascading effects, must have deliberate friction (intentional obstacles). Here are the core principles and standards that DirectAdmin currently overlooks in this process:

The Principle of "Necessary Friction"​

In critical systems, a destructive action should never be completed with a simple click or an accidental ENTER. Best practices require Positive Confirmation. Instead of a checkbox that is "checked by default" (e.g., "Delete Users of this Reseller"), the system should require an active manual toggle or, even better, require the user to type the Reseller's name or the word "DELETE" to confirm the action or other preventive mandatory action.

Nielsen’s Heuristics (Error Prevention)​

According to Jakob Nielsen’s 10 Usability Heuristics, #5: Error Prevention states that a design should either prevent a problem from occurring in the first place or check for it and present users with a confirmation option before they commit to the action. By pre-selecting the "Delete Users" option, the interface essentially "designs for error" rather than preventing it.

The "Confirm-Before-Destruct" Standard​

Modern engineering standards dictate that a system must present the full impact of an action before execution:

• Poor Design: "Are you sure you want to delete this Reseller?"
• Robust Design: "Are you sure? This action will permanently remove the following 15 Users, 40 Databases, and 200GB of data. This action is irreversible."

Lack of Referential Integrity Checks​

The system should perform a "double-check" between the internal database (the .list files) and the actual filesystem. If a Reseller deletion is triggered, the software should scan the /home directory for any "orphan" or "invisible" users that might not be correctly indexed in the panel's cache to avoid unintended data loss.

Conclusion:Relying on "the admin should know what they are doing" is no longer an acceptable standard for modern SaaS or Control Panel software. We need more safeguards to prevent catastrophic data loss caused by a single misclick.

Deleting in cascade when users in disk missed in user.list .. hummm something can be done better.

you should create the ticket.

that way, DA can reproduce the issue, and fix it if there is any.

You are absolutely right... i'll do that

 

[bitpt]

There is another critical flaw in DirectAdmin's hierarchical logic, especially regarding Resellers created by the Admin:

The Scenario: When the admin creates a Reseller account (e.g., reseller_user), that account is technically owned by the admin. This Reseller then goes on to create and manage 30 other Users.

The Problem:

Lack of Self-Management: The Reseller has full control over their 30 Users but has zero control over their own account’s resources (packages, limits, etc.). To change their own hosting features, they must contact the admin.

Transfer Dead-end: It is impossible to transfer the Reseller's own account to the Reseller themselves. The system rejects this because a user cannot be their own "creator" in the current flat-file hierarchy.

The Logical Loop: Because DA uses a "creator/created" string in a text file instead of a relational database with flexible permission roles, the Reseller is perpetually "orphaned" from their own account management.

Conclusion: This creates a massive administrative bottleneck. A Reseller should be able to manage their own hosting environment if granted permission, but the current legacy structure of "Admin-owned Resellers" makes this impossible to resolve without messy manual workarounds.

Perhaps I'm misinterpreting the logic here... am I?

 

[Richard G]

but has zero control over their own account’s resources (packages, limits, etc.). To change their own hosting features, they must contact the admin.

Where do you get that idea from? Every reseller can create their own packages for his customers depending on the total resources he gets from the admin, that is not different then on any other panel. Who creates the reseller is not interesting.
So there is no lack of self management.

It is impossible to transfer the Reseller's own account to the Reseller themselves.

Not required, this part is different than with cPanel. A reseller is just like an admin both reseller and user, so what do you want to transfer op himself to his own account. That sounds very strange to me.

Reseller is perpetually "orphaned" from their own account management.

I don't know any panel where a reseller can manage their own account in the sense of raise the resources they get when the become reseller.

Perhaps I'm misinterpreting the logic here... am I?

Yes you are. Who else should create Resellers then? Root? It doesn't matter in any way if it's root or admin.
In cPanel is a Reseller is technically owned by root, so what is the difference? Reseller is still limited in what he/she can do.

The issue what you experiences is almost 99% certainly a result of a conversion from cP to DA issue. I can't remember having seeing someting like that in my DA career where it was not solvable.

 

[bitpt]

Let's look at a very simple, practical example of why this ownership logic is flawed:

If an Admin creates a Reseller with the domain xpto.com, that domain is tied to the Reseller's main account.

Now, if that Reseller needs to change something as fundamental as their own DNS records or hosting limits, they often find themselves locked out of their own management. Why? Because the reseller user is owned by the admin.

In a flexible system, the Reseller should have full autonomy over their own primary domain. In DA, they are treated as a 'sub-user' of the admin for their own account, while being a 'master' for others.

If I cannot easily transfer that primary account to the Reseller's own control to break this dependency, it’s a clear sign of a rigid architectural limitation. It’s not about 'strangeness', it’s about administrative independence.

Just to be clear, my observations aren't about comparing panels. I work with ISPConfig, CyberPanel, and others, and each has its own philosophy. My focus here is strictly on operational security and data integrity.

The goal isn't to make DA act like cPanel; the goal is to have a safe and efficient process. Regardless of the panel, if a mass-deletion can be triggered 'silently' due to a cache mismatch or a rigid ownership structure, that’s a technical risk that needs to be addressed for the benefit of all users.

It seems the only viable 'workaround' here is to create a Reseller with a dummy domain (fake-domain.site) and then create the actual production domain as a separate User account under it. This way, the Reseller has full autonomy over their real site.

DirectAdmin may have worked like this for centuries, but for someone coming from a background of diverse environments, this 'parent-child' restriction on primary accounts feels outdated. It's a steep learning curve, not because it's complex, but because it lacks the administrative flexibility found in modern relational-model panels.

I'm here to learn the 'DA way,' but I'll still advocate for a more secure and intuitive process when it comes to destructive actions.

To conclude, the only major hurdles I’ve encountered are related to the User/Reseller/Admin hierarchy and the cache-driven UI. Everything else, backups and restores from other environments, works flawlessly. Aside from a few normal server configuration tweaks, the core performance is solid.

My critique is focused solely on making the account management and deletion process more robust and secure. DirectAdmin has many strengths, and by addressing these UX and architectural 'blind spots,' it could be even better. Thanks for the insights, everyone.