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

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
 
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.
 
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.
 
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.
 
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.
 

Attachments

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...
 
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.
 
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.
 
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:

Bash:
[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
 
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.
 
Back
Top