Prevent default domain deletion or change

Stumbled across this today too.

... so I'm guessing this was never resolved?

There may be an option that disabled this. But trying to find the correct option to flag is really a tough exercise with DirectAdmin scattered documentation.

For billing purposes use LOGIN instead of domain name. Users/resellers can't modify their logins.

The

/usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh

Looks like it would accomplish what I need and this will work just fine.

I suppose to stray this a bit off-topic, but to my point about documentation... is there a list of all of the /usr/local/directadmin/scripts/custom available hooks? And then what environment variables are passed to each hook would also be beneficial. Is that information any where in any central location?

The one issue with the code in - /usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh -

Code:

#!/bin/sh

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

    echo "Cannot delete the default domain";

    exit 1;

fi

exit 0;

Is that it will create issue if the account (i.e - the username) is deleted by the admin or reseller (I presume). The domain won't get fully deleted with this code present.

My solution to this was to modify the code slightly:

Code:

#!/bin/sh



if [ -z "${creator}" ]

then

        if [ "$defaultdomain" = "yes" ]

        then

                echo "Cannot delete the default domain";

                exit 1;

        fi

        exit 0;

fi

It would seem that the ${creator} environment variable is not present when the domain_destroy_pre hook is called from within a user's control panel. But it is present when deleted from the admin panel (or at least using the API). So you check for the existence of the ${creator} variable and if it's not found, then you check to make sure the domain name is not the default domain before exiting.

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

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?

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…

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

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.

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.