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

[zEitEr]

Right place or when some problem come go to another place?

Whatever... It's community forums. We can not help you I believe. If you really need a solution, you might talk with DirectAdmin developers. I don't work for DirectAdmin, and I am not their choice-maker either. Thank you for your time

 

[Richard G]

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.

No that is totally not true. It's the same as with cPanel, give me an example of what a reseller can do in cpanel and can not in in DA.
Resellers can do as they want with their account. So they can also change DNS records, even their own. And hosting limits are set by the creator in any panel, either if it's root or admin totally doesn't matter.
Doesn't matter if they are sub user of system, root or admin, totally makes no difference as a reseller is never a main user.
As a reseller is never ever an admin on any panel (except in DA admin himself) there will always be restrictions, that's why it's reseller and not admin.

I still don't know where you get the idea that you would not be able to change your main domain as reseller because you can, even a user can. So that statement is not true at all.

Again, the issues you're pointing out now, are normally never to be seen and a warning is visible. So as said this must have to be related to something going wrong with CP to DA conversion. And conversions are in most systems never 100% perfectly.

This is not the place to discuss things which would not work, because it would spoil answers to the issue you are having now caused by the conversion.
If using a normal DA installation, I'm happy to proove to you that there are warnings and it's also logical that if you delete a reseller the whole tree (so everything below the reseller) is deleted to. And I've seen then warning before when deleting a reseller.

If I create a Reseller with domain.com, that Reseller cannot manage that primary domain's DNS or settings directly within their Reseller interface.

I have admin access but my company account is reseller and I don't know which DNS settings you can't change for the primary domain, because I can and I even use my own nameservers.
Check these things and make your statements after you have a correct working DA system and not one which is crippled due to a conversion issue.

As said I would gladly discuss this in off-topic or somewhere else, because you can close all you want but it's based on false statements.

 

[zEitEr]

Resellers can do as they want with their account. So they can also change DNS records, even their own. And hosting limits are set by the creator in any panel, either if it's root or admin totally doesn't matter.

I believe it is about hosting limits applied to the user account of the reseller, such as disk space, number of domains etc, which are counted under total limits of a reseller.

 

[Richard G]

I believe it is about hosting limits applied to the user account of the reseller,

That's what I'm wondering about, as in my first comment I already stated I don't know -any- panel as where a reseller can change his own limits. Which is logically because a reseller is no admin/root so always has the limits it's setup with. And since he comes from CP, also there a reseller can not change his own limits like disk space.

 

[bitpt]

I believe it is about hosting limits applied to the user account of the reseller, such as disk space, number of domains etc, which are counted under total limits of a reseller.

No, it is not. I have my main license and a temporary license on another server (a bridge server) that I use to migrate accounts from cPanel, CyberPanel, ISPConfig, and servers without any control panel.

On the temporary‑license server, where I performed these tests, I moved two accounts between resellers and they ended up merging into a single one… grrr… I almost gave up.

Now, on the production server, the reseller has access to the main account, but on the bridge server they do not. With the help of an AI, I developed a different structure to handle this, which prevents user‑related mistakes.

Use at your own risk.

 

[bitpt]

That's what I'm wondering about, as in my first comment I already stated I don't know -any- panel as where a reseller can change his own limits. Which is logically because a reseller is no admin/root so always has the limits it's setup with. And since he comes from CP, also there a reseller can not change his own limits like disk space.

Is not limits, is limits for your own domain.. change DNS and so on

Now one server is ok, the other one, no...

 

[Richard G]

is limits for your own domain.. change DNS and so on

As said, I don't have those issues with my reseller account. So it is possible with DA otherwise I couldn't either.

 

[zEitEr]

Use at your own risk.

Thank you, I'm fine

As said, I don't have those issues with my reseller account. So it is possible with DA otherwise I couldn't either.

It seems the Topic Starter is not for a solution here. The user either has a customized skin or has limited permissions on the server. The second is less possible, since the user mentioned having a license.

 

[bitpt]

I appreciate the 'fine' and the 'works for me' comments, but let’s talk about engineering instead of anecdotes.

In over 20 years of sysadmin experience, from cPanel to ISPConfig and CyberPanel, and others I’ve learned that 'it works for me' is not a security protocol. The fact that DirectAdmin still relies on flat .txt files in /usr/local/directadmin/data/users/ as a single point of truth is an architectural choice from the 90s.

When you are managing hundreds of gigabytes and high-traffic environments, a silent corruption or an accidental rm on a flat-file shouldn't lead to a "ghost user" or data loss. In modern environments (like Enhance or even cPanel’s internal DB tracking), there is transactional integrity. If a write fails, the system rolls back. In DA, if the file is gone, the metadata is gone.

The SQLite hybrid solution I proposed isn't because I 'don't know how to use a Reseller account' or because of a 'custom skin'. It’s because metadata deserves a relational structure with ACID properties, not just a simple text string that any process can wipe.

I’m glad you haven’t had issues yet. But relying on the OS to never fail a file-write isn't 'best practice' it's just luck. I’m looking for a system that handles errors gracefully, not one that ignores them until it's too late.

It is disappointing to see that, over time, many veteran users become "fanboys" who blindly defend the tool instead of looking at technical issues with clarity and transparency.

If the community consensus is 'it's fine because it hasn't happened to me', then it’s clear that DA is no longer evolving for enterprise-grade reliability. I'll stick to my hybrid SQLite protection for now, as I prefer my data integrity to be managed by code, not by hope.

Since the consensus here seems to be that architectural flaws are acceptable as long as they haven't affected everyone yet, I will no longer seek technical insight in this thread. I will rely on my own hybrid SQLite protection and contact official support directly for actual technical issues. I prefer my data integrity to be managed by code and databases, not by hope. .... And for sure, I will never come back here again. There is no need to reply because I won't be reading it. I know you only feel the need to answer so that other users reading this see a 'curated' image, but as far as I'm concerned, I'm done with this forum.

 

[zEitEr]

contact official support directly for actual technical issues

That's good you follow this way. That's the best thing you might do I guess.

Meanwhile DirectAdmin is using SQLite already for some operations. You can check it with:

[root@poralix admin]# sqlite3 /usr/local/directadmin/data/admin/system.db
SQLite version 3.46.1 2024-08-13 09:16:08
Enter ".help" for usage hints.
sqlite> .tables
db_temp_user           global_values          taskq_schedule_log
directadmin_migration  license_history
sqlite>

[root@poralix admin]#

The only changelog related to the matter found here: https://docs.directadmin.com/changelog/version-1.660.html#prevent-sqlite-errors-on-very-busy-servers (it is Version 1.660)

p.s. I understand your concern, but you still use text based OS like Redhat/Ubuntu/Debian/AlmaLinux/etc I believe

 

[sysdev]

Well, txt files are somewhat the linux way to do things. Losing 'users' isn't. I have never had any issues related to this, but if it is possible, it should be addressed and fixed. Easy enough.
But in general, all things can break for many reasons. That's why we have backups or snapshots, to prevent deletions from becoming catastrophic.

 

[bitpt]

p.s. I understand your concern, but you still use text based OS like Redhat/Ubuntu/Debian/AlmaLinux/etc I believe

Are you joking? I said I wouldn't post here again, but I couldn't resist after seeing this 'tech joke'.

Comparing an OS configuration file to a Hosting Panel's metadata management is a massive technical fallacy. Modern Operating Systems use journaling file systems (EXT4, XFS), rpm/dpkg etc, and complex binary structures precisely because flat text files lack ACID properties (Atomicity, Consistency, Isolation, Durability).

If a server crashes or a process fails while writing to a .txt file, you end up with a corrupted or 0-byte file. If it happens during a proper Database transaction, you get a rollback. That is the fundamental difference between professional metadata management in 2026 and 90s-style legacy architecture.

Instead of wasting time coming up with these poor excuses, it would be much more productive to spend some time studying and learning how these things work. Using "text-based OS" as a shield for poor data integrity is not only technically wrong, it's misleading.

 

[zEitEr]

Are you joking? I said I wouldn't post here again, but I couldn't resist after seeing this 'tech joke'.

So if you accidentally overwrite passwd, shadow, other files under /etc/ or run chmod -R admin:admin / your OS will keep running? Will your OS survive with all those journals if you run rm -rf /? I guess no...

 

[Richard G]

I just wanted to reply to 2 lines.

I’ve learned that 'it works for me' is not a security protocol.

We can agree on that. I also don't think that "works for me" is proove that it works good for all. However, in this case I only intended to proof that your statement was wrong and you can change resellers DNS settings for example. You didn't acknowledge that, which is your choice but it is a fact.

many veteran users become "fanboys" who blindly defend the tool instead of looking at technical issues with clarity and transparency.

I feel a bit offended with that statement, as I am a veteran user "defending" the system in this thread. But not as you say because not looking at technical issue but because at this moment there was 0 proof on the statements you made about a reseller account, you in fact made false statements which were not true at all.
So now suddenly you change to security and other things, but that does not take away the fact that those statements were false and things are working as designed but only you have a problem.

My thought was that first you take care that you have a normal working DA system, no conversion stuff. Then use it and only then state what does or does not work.

Ofcourse, like with any other panel, DA will have some security shortcomings, although indeed Linux is also based mostly on textfiles.
But CP also has it's issues, even things they can't fix so they say just ignore it instead of fixing it. We have CP server too.
Silent corruptions can also arise in databases like sqlite. And CP does not roll back everything automatically. Not even spoken about that fact that a very big, very old and very very expensive panel does not even support ipv6 fully at this moment!!! In 2026 now!
So please don't come here with 90's statements as CP even doesn't have this one fully ready yet while DA is fully working with ipv6 for almost a decade now if I remember correctly. I use CP as example because I don't kow about the rest and never compare a professional panel with a free panel.

You can't fully compare the sqlite and text file usage as DA is build so the hosters can more customize it to their likings, something which is not possible with several other panels.
To be able to do this, you have to use some different structures. Try repairing CP. If something goes wrong with DA people know where to look and can fix things themselves.
They all have their pro's and cons. Lots of things have improved the last years and added.

If you want to discuss technical things to improve, start a discussion about that in another forum section, but don't start complaining about things you say don't work while they work and you're only frustrated about the fact that you lost users.
Then making statements about resellers not being able to do certaing things and if prooven wrong, then suddenly change to things you don't find secure these days.
If it's that bad in your eyes, why change to DA?

Instead of wasting time coming up with these poor excuses

You might first stop being offending and acknowledge you were wrong about reseller abilities.

 

[Ohm J]

if database curruption, this will cause big issued than pure file text.
and support ticket might increase due this issued.

Or we can called " Big Data Loss "

 

[bitpt]

you in fact made false statements which were not true at all.

Never call a user a liar when they are providing technical evidence. Here is the 'ghost in the machine' you claim doesn't exist. These are my server logs: (yes i can prove it called by GUI without no warning)

2025:12:30-19:50:47: User xxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:50:47: Domain xxxxx.com deleted via User deletion
2025:12:30-19:50:48: User bbbbb removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:50:58: Domain xxxxxxx.eu deleted via User deletion
2025:12:30-19:51:10: User xxxxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:11: Domain xxxxx.com deleted via User deletion
2025:12:30-19:51:17: User xxxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:17: Domain xxxx.com deleted via User deletion
2025:12:30-19:51:19: User xxxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:21: Domain xxxxx.com deleted via User deletion
2025:12:30-19:51:22: User xxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:22: Domain xxxx.com deleted via User deletion
2025:12:30-19:51:23: User xxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:23: Domain xxxxx.com deleted via User deletion
2025:12:30-19:51:23: User xxxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0'
2025:12:30-19:51:24: Domain xxxxxx.fr deleted via User deletion
2025:12:30-19:51:25: User xxxxx removed because resel1 was being deleted: accountability='Command call 1: caller=admin ip=111.111.111.111 api=0' ....


"As the logs clearly show, the system triggered a cascade deletion of multiple independent users and their domains simply because 'resel1' was being deleted. This happened in a matter of seconds.

If your 'rock solid' architecture allows a single action to wipe out multiple users without a clear recursive warning or a transactional fail-safe, then it is a flawed architecture. I am not here to argue with fanboys; I am here reporting a catastrophic data loss event backed by logs. If you prefer to ignore evidence and resort to name-calling, it only proves my point about the lack of transparency here.

If it's that bad in your eyes, why change to DA?

Simple: because I made a bad choice. I am human, I make mistakes, and choosing DirectAdmin was one of them. I am already solving it and moving away from this legacy architecture, which takes time. I’d rather admit a mistake and fix it than stay blind to technical flaws.

So if you accidentally overwrite passwd, shadow, other files under /etc/ or run chmod -R admin:admin / your OS will keep running? Will your OS survive with all those journals if you run rm -rf /? I guess no

Are you seriously comparing a deliberate 'suicide' command like rm -rf / or manual file corruption to a software's internal logic failing to protect its own metadata?

A professional hosting panel is an abstraction layer. Its ENTIRE purpose is to prevent exactly what happened in my logs: a cascade of unintended deletions. When I delete a Reseller, the software should have enough architectural integrity (and ACID-compliant databases) to ensure that only that entity is affected, or at the very least, provide a transactional rollback.

Operating systems have binary logs, journals (EXT4/XFS), and recovery tools to survive hardware and filesystem failures. DirectAdmin has flat .txt files. If you can't see the difference between 'User Error' and 'Architectural Vulnerability', then you clearly don't know what a binary structure or a journaled system is for. I’m fixing my 'bad choice' by building my own API-based control layer. Keep your flat files and your luck; I’ll stick to engineering.

But CP also has it's issues

I never said Panel A, B, or C is perfect. Every system has issues. But I didn't come here to start a 'panel war' or debate which UI is prettier. I came here because I lost 200GB of data and several hours of work due to a documented cascade failure, and all I found were excuses and denial.

The issue isn't that cPanel or others are 'better'; the issue is how a community and a dev team react when a catastrophic failure is reported. Instead of technical analysis, I got .... this. My logs don't lie. My data loss is real. If your only answer to a 200GB wipeout is 'but the other guy is also bad', you are missing the point of professional hosting entirely. Now ... is really last post .. my time isn't to wast with this

 

[zEitEr]

When I delete a Reseller, the software should have enough architectural integrity (and ACID-compliant databases) to ensure that only that entity is affected, or at the very least, provide a transactional rollback.

Then you might read docs first:

- https://evo.site-helper.com/evo/admins/alistr.html#deleting-reseller

it says:

Warning: Deleting a Reseller means his/her account and all accounts (Users) he/she created will be deleted.

The case with removal of admins is treated differently:

- https://evo.site-helper.com/evo/admins/acreate.html#deleting-administrator

Note: Deleting an Admin will not delete the Resellers created by that Admin.

 

[LawsHosting]

Reading this thread annoyed me........

1. We all do backups for this reason;
and
2. Your database argument - all databases are text files too, so not sure of your argument here;

Educate me.

 

[Richard G]

Never call a user a liar when they are providing technical evidence.

I suggest you read what you stated and especially the part where I said "where no conversion has taken place"!

We are with thousens of DA customers, seems this only has happend without notice after a conversion.
I didn't call you a lyer, I stated you first have to use a clean DA installation, so no conversion, and then make your statements, instead of making all kinds of false statements where almost certainly these are caused by conversion issues.

But I didn't come here to start a 'panel war

Again, read what I wrote. I didn't start a panel war, I used cp as an example because I never compare with free systems, which I clearly stated.

the issue is how a community and a dev team react when a catastrophic failure is reported.

As said. This is a very curious and special catastrophic issue which we have never seen before here, only to be seen now after a conversion.
Community is no dev's and @zEitEr already stated he is not part of the dev team, just a moderator.
It was suggested multiple times to send in a ticket!

For the rest I won't discuss further as it's going nowhere. Suggestions for security improvements are welcome in a seperate thread, it won't solve this issue, neither will discussing your thoughts about DA.

 

[fln]

Hi everyone. It seems the discussion heated up pretty quickly. Let me share how we see the situation.

@bitpt thank you for sharing your experience. The situation you got into is really frustrating. We really want DirectAdmin users to never have to go through such situations.

As with all disasters, there is rarely a single problem causing it. A chain of unfortunate events and incorrect assumptions is more common.

---

1. The most important problem here is finding out how one can end up with "ghost" users. The existence of a "ghost" user is a clear sign of malformed system configuration. If it is possible to create such a situation with a set of actions in the DA interface (not by manually editing internal DA files), this would be the most important thing for us to find and fix.

If there are "ghost" users on the system, the best course of action would be contacting tech support. This would allow us to search for clues on the server about how this might have happened. And even if we find nothing, then at least we could fix the DA configuration files.

---

2. The second problem was the missing warning on the user delete action. It is quite hard to reliably show valid data on the malformed system. Nevertheless, we could improve it. The root problem here is not the plain-text files. It is multiple sources of truth (multiple ways we can detect which users belong to a particular reseller). In the UI the list of accounts owned by a particular reseller was detected in a different way than it was detected when the reseller account was actually being removed.

The veteran DA users are all aware that account deletion always removes the sub-users as well. For them the missing number of sub-users in the user deletion warning seems more like a UI quirk, not a fundamental problem. But for the new DA users, an incorrect warning message can lead to this catastrophic outcome.

---

Improvements for the first or second issue will prevent a similar situation from happening in the future for other users. However, we do not have enough information on how "ghost" users were created, so we can only focus on updating the account delete action warning.

---

---

The DB versus plain-text files discussion is slightly off-topic in my opinion. I think both camps (plain-text/DB) are right in their own way. Different camps are looking for solutions to different problems in different environments and with different constraints. Here are some of the less obvious points about the plain-text files:

• Data consistency. Data consistency in a single file scope is not a problem. We use atomic operations to replace file contents. A new temporary file with new contents is created. Once it is fully written, it is atomically swapped with the old file. Killing the process at any point will never leave the main config file empty or partially written or malformed. Reading the main config file at any point in time will never give you incomplete or malformed data. Data consistency among multiple files is a harder problem. We address it with file locks.
• Data corruption resilience. Database file corruption is much more likely than plain-text file corruption. All the system administrators know that just copying the files of a live database engine is a guaranteed way to get a malformed DB. I mean that no one is using cp on the /var/lib/mysql directory for backups. The same applies for SQLite. The official SQLite documentation has a special page on how to corrupt the DB. Backup or restore while a transaction is active is one of the well-known ways. Because DA uses plain-text files, it is possible to just make a copy of any DA data directory or file for backup purposes and restore it later. This is handy for skilled server admins.
• Handling corruption. Restoring corrupted or missing plain-text files is much easier than restoring a database binary file. To get the ACID properties from the database engine, we need to use a single database instance for all the data. This means with data corruption in the main database, you lose all the data. With multiple plain-text files you can corrupt one file and lose some data, but not all the data. You can fix a malformed plain-text file with the text editor. But you need specialized tools for recovering data from a binary DB file.
• Visibility. By using plain-text files, DA allows experienced system administrators to show how the system works. Every file can be easily inspected with the standard file editor. All data structures are visible, and a simple diff command can reveal any changes DA made to the system after an operation via UI is performed.
• Integrations. A lot of DA users have extended or integrated DA with external systems by using plugins, custom hooks, or external scripts. The plain-text files make it easier to manipulate DA data. This is a double-edged sword, though. Most of the problems users encounter are caused by customizations or tampering with DA config files .
• External software configs. The biggest value DA creates is the ability to reconfigure external software. This means creating config files not for DA itself to consume, but for other software to use. For example, when creating a new DA user account, we need to create a UNIX account as well (touch /etc/passwd, /etc/shadow, make home directory). When domain configuration is changed, we need to regenerate web server configuration files. Most of the software on Linux systems is controlled by plain-text configuration files. So even if DA internally uses a transactional database, we still need to address the consistency concerns of 3rd-party configurations. The transactional DB could roll back the records inside the DB if some operation failed, but it will not roll back external software configuration files. We still need all the consistency primitives like atomic writes, file locks, and careful ordering of actions when working with external files. We can reuse the same tools for internal files as well.

Please do not get me wrong. I am not claiming that plain-text files are superior to transactional DB. Each comes with its own benefits. But I can assure you plain-text files do not make it impossible to have a reliable system. It is harder for developers to work with but more convenient for system administrators . I think that is the reason why DA veterans see no problems with it. It is also the reason why using plain-text files is considered "the UNIX way" and preferred by a lot of server management software.

For anyone who would be creating a new control panel from scratch, using SQLite for internal data storage would be a fair design decision. As @zEitEr pointed out, we already store some data inside the SQLite databases (there is one global DB and one DB for each DA user). Those DBs are not heavily used by DA at the moment but give us more options for the future.

We are actively working on upgrading various aspects of how DA works, but we are doing it in small steps. The backwards compatibility is what holds us back the most. Thanks for your feedback @bitpt. This incident will help us improve DA.