Prevent default domain deletion or change

Quoted from Guest on Saturday, 27 December 2025

So, how do you check if a domain is no longer in use within DirectAdmin to ensure it's available for provisioning in WHMCS?

How would you do that anyway since users can have dozens of domains but only one is listed in WHMCS? DirectAdmin is not going to let a user provision a domain that already exists anyway.

Quoted from Guest on Saturday, 27 December 2025

provisioning in WHMCS?

Do you mean when somebody signs up and provides a domain or are you talking about something else?

The way I use both WHMCS and DA domains are just not relevant at all. I could delete the domain in WHMCS completely and it would not make a difference in WHMCS or DirectAdmin. So perhaps you can explain a little more about your thought process.

My thought process is this:

Previously when a user signed up WHMCS would create the username on DA based on the domain name and also add that domain to their DA account. Many complained that they didn't want their username to be based on their domain so I added instructions to intead of putting their domain name to put in the username they wanted up to I think it was 8 characters with a .com as the extension. Then login to DA and delete the fake domain it created. The result was the user got the username they wanted.

Now I have WHMCS create a random username. Most seem to like that ok.

The point is the domains never needed to sync with WHMCS for anything to work properly.

Quoted from Guest on Saturday, 27 December 2025

I have been using both for many, many years and never had a problem. The main domain in DA rarely matches in WHMCS and I have never had a issue nor do I see why it would

So, how do you check if a domain is no longer in use within DirectAdmin to ensure it's available for provisioning in WHMCS?

Quoted from Guest on Saturday, 27 December 2025

The main reason is the synchronization with WHMCS. If you change the main domain in DirectAdmin, it breaks the link with the billing system (WHMCS), causing errors with renewals and support automation. It's a limitation on the WHMCS side that requires the domain to match exactly.

I have been using both for many, many years and never had a problem. The main domain in DA rarely matches in WHMCS and I have never had a issue nor do I see why it would

Update: I have revised the guide above based on direct feedback from DirectAdmin support.

Jonas from the support team confirmed that all_pre.sh is the correct hook to intercept this specific action (action=select), but he warned about performance implications since this hook runs on every command.

Here is the specific advice from support that led to the optimized all_pre.sh script I shared:

Hello,

As far as I can see primary hook for that action(general "command" interface) is all_pre.sh, where something like following can be used:


Bash:
#!/bin/bash

if [ "$command" == "/CMD_DOMAIN" ] && [ "$action" == "select" ] && [ "$default" == "yes" ]; then

   echo "changing default domain not allowed"

   exit 1

fi

Not the best hook. Customization should be as fast as possible, as it will hook into lots of other actions.

Best Regards

The final script I provided in the tutorial includes the necessary performance filter (if [ "$command" != "/CMD_DOMAIN" ]...) to address this concern and ensure the server remains fast.

Quoted from Guest on Saturday, 27 December 2025

I don't see why it matters. Not being able to manage my domains the way I see fit would be cause for me finding another hosting company.

The main reason is the synchronization with WHMCS. If you change the main domain in DirectAdmin, it breaks the link with the billing system (WHMCS), causing errors with renewals and support automation. It's a limitation on the WHMCS side that requires the domain to match exactly.

I don't see why it matters. Not being able to manage my domains the way I see fit would be cause for me finding another hosting company.

Quick update: I haven't found a perfect workaround to block users from changing their Default Domain yet. None of the standard hooks seem to catch this specific action in the Evolution skin.

For now, I'm using public_html_link_set_pre.sh as a temporary fix—it stops the change on the backend, but the UI still shows 'Success' (false positive). I’ve opened a ticket with DirectAdmin support to find a proper solution. I'll update here once I have a fix!


Bash:

#!/bin/bash



# 1. ALLOW ADMIN/RESELLER

if [ -n "$caller_username" ] && [ "$caller_username" != "$username" ]; then

    exit 0

fi



# 2. RETURN ERROR

# If "json" variable is present, try to return JSON error for the panel.

if [ "$json" = "yes" ]; then

    echo '{ "error": "1", "text": "PERMISSION ERROR", "details": "You are not allowed to change the Main Domain. Please contact support." }'

    exit 1

fi



# Fallback for terminal/old skin

echo "SECURITY ERROR: Changing Main Domain is forbidden."

exit 1

public_html_link_set_pre.sh

Quoted from Guest on Saturday, 27 December 2025

Thank you.
However it would be nice if Directadmin would make things a bit more structural or similar.

Now we got several settings which use the "user_can" this or that in singular.
Like for example:
user_can_select_skin
user_can_set_email_limit
user_dnssec_control=0

Only the renaming/adding/deleting domain uses the "users_can" where users are in plural. This makes things a bit confusing or rather more eligible to make a mistake.

@fln wouln't it be a good idea to make this consequent? So it would be either plural or singular for all commands?

At this point im doubting if DA code changes get reviewed…

Thank you.
However it would be nice if Directadmin would make things a bit more structural or similar.

Now we got several settings which use the "user_can" this or that in singular.
Like for example:
user_can_select_skin
user_can_set_email_limit
user_dnssec_control=0

Only the renaming/adding/deleting domain uses the "users_can" where users are in plural. This makes things a bit confusing or rather more eligible to make a mistake.

@fln wouln't it be a good idea to make this consequent? So it would be either plural or singular for all commands?

Hello, thanks for all information this give me a direction to get it done, so to save for future and others I'm showing below how I did, I used IA to explain with details:

We manage a DirectAdmin environment and have specific requirements for user permissions regarding domain management:
Renaming: Users must NOT be able to rename ANY domain (Main or Addon).
Deleting: Users CAN delete Addon domains, but must NOT be able to delete the Main Domain.

Here is the configuration we implemented to achieve this hybrid control.

1. Disable Renaming Globally (directadmin.conf)​
Since we want to block renaming for all domains, we rely on the native DirectAdmin configuration.In /usr/local/directadmin/conf/directadmin.conf:

Code:

users_can_rename_domains=0

This removes the rename functionality for the user entirely. https://docs.directadmin.com/changelog/version-1.61.0.html#block-domain-rename

2. Allow Domain Deletion Globally (directadmin.conf)​
To allow users to manage their Addon Domains, we must ensure the global setting allows adding/removing domains:In /usr/local/directadmin/conf/directadmin.conf:
Code:

users_can_add_remove_domains=0

(Note: 0 is the default value which means "Allowed". If set to 1, users cannot delete any domain). https://docs.directadmin.com/change...ins-user-conf-to-block-domain-adding-deleting

3. Protect Main Domain from Deletion (Custom Hook)​
Since the global setting allows deletion, we use a custom script to intercept the delete command and block it only if the target is the Main Domain.

Create/Edit: /usr/local/directadmin/scripts/custom/domain_destroy_pre.sh
Bash:

#!/bin/bash



# 1. QUEM ESTÁ EXECUTANDO A AÇÃO?

# Se caller_username estiver vazio, assumimos que é o próprio usuário ($username).

# Se tiver valor (ex: admin), usamos ele.

if [ -z "$caller_username" ]; then

    QUEM_ESTA_FAZENDO="$username"

else

    QUEM_ESTA_FAZENDO="$caller_username"

fi



# 2. PROTEÇÃO PARA ADMIN/RESELLER

# Se quem está fazendo a ação FOR DIFERENTE do dono da conta,

# significa que é um Admin ou Reseller gerenciando o cliente.

# Nesse caso, permitimos tudo (exit 0), inclusive deletar a conta inteira.

if [ "$QUEM_ESTA_FAZENDO" != "$username" ]; then

    exit 0

fi



# -----------------------------------------------------------------------

# DAQUI PARA BAIXO, SABEMOS QUE É O PRÓPRIO USUÁRIO TENTANDO DELETAR ALGO

# -----------------------------------------------------------------------



USER_CONF="/usr/local/directadmin/data/users/${username}/user.conf"



# Verifica se o arquivo de configuração existe

if [ -f "$USER_CONF" ]; then

  

    # Pega o domínio principal e remove possíveis espaços em branco (xargs)

    MAIN_DOMAIN=$(grep "^domain=" "$USER_CONF" | cut -d= -f2 | xargs)

  

    # Pega o domínio que está sendo deletado e remove espaços

    DOMAIN_ALVO=$(echo "$domain" | xargs)



    # Compara os dois

    if [ "$DOMAIN_ALVO" = "$MAIN_DOMAIN" ]; then

        echo "ERRO DE SEGURANCA: Voce nao pode deletar o dominio principal da conta."

        echo "Para cancelar sua conta ou alterar o dominio principal, contate o suporte."

        exit 1

    fi

fi



exit 0

4. Protect "Set Default Domain" (The tricky part)​
Blocking the "Set as Principal/Default" button in the Evolution skin is tricky because it doesn't always trigger the standard hooks cleanly. Thanks to DA support advice, we found that checking the specific action in all_pre.sh is the most reliable method.

Note: To avoid performance issues, we exit the script immediately if the command is not CMD_DOMAIN.

Create/Edit: /usr/local/directadmin/scripts/custom/all_pre.sh

Bash:

#!/bin/bash



# 1. PERFORMANCE FILTER

# If the command is NOT CMD_DOMAIN, exit immediately.

# This ensures we don't slow down the server checking every single action.

if [ "$command" != "/CMD_DOMAIN" ]; then

    exit 0

fi



# 2. BLOCK LOGIC

# The Evolution skin sends action="select" and default="yes" when setting a new main domain.

if [ "$action" = "select" ] && [ "$default" = "yes" ]; then



    # 2.1 ALLOW ADMIN/RESELLER

    if [ -n "$caller_username" ] && [ "$caller_username" != "$username" ]; then

        exit 0

    fi



    # 2.2 BLOCK WITH JSON ERROR

    # We return a JSON error so the Evolution skin displays a Red Box alert

    # instead of failing silently or showing a false success.

    echo '{ "error": "1", "text": "PERMISSION ERROR", "details": "You are not allowed to change the Default Domain. This action breaks billing synchronization. Contact support." }'

    exit 1

fi



exit 0

5. Set Permissions​
Don't forget to set the correct permissions for the script:
Bash:

chown diradmin:diradmin /usr/local/directadmin/scripts/custom/domain_destroy_pre.sh

chown diradmin:diradmin /usr/local/directadmin/scripts/custom/all_pre.sh

chmod 700 /usr/local/directadmin/scripts/custom/domain_destroy_pre.sh

chmod 700 /usr/local/directadmin/scripts/custom/all_pre.sh

Summary of Result​

• Renaming: Totally disabled for users (via directadmin.conf).
  
• Deleting Addon Domains: Allowed.
  
• Deleting Main Domain: Blocked (via domain_destroy_pre.sh).
  
• Changing Default Domain: Blocked (via all_pre.sh).
  
• Admin/Reseller Actions: Fully allowed (scripts bypass if caller != username).