User/Reseller Management Hooks

This script is called before a reseller is deleted.

The reason for having this script is that if you delete a Reseller, adding the reseller and users to the won't be sufficient, in that a lot of deletion cleanup is done prior to the reseller's user portion actually being removed (which is when the is finally run)... so the isn't sufficient to cover some cases.

This script will be handy if you want to prevent the deletion of an account, or a specific account (Reseller or User) below it.

Environment variables


These hook scripts are called before/after a reseller config file is modified.

Environment variables

  • contents of user's reseller.conf and, during the pre script, the data from the request body.
  • modified_by: reseller who makes the modifications


These scripts are called before/after a user/reseller/admin is created.

Environment variables

  • passwd: password set for user
  • contents of user.conf

This hook is called after the user.conf is written (for user creation).

Note, this feature request was initially made with the in mind (for

However, after looking at the code, it was found that the write for the domain confs are done quite early on in the creation, so the is in fact called at the correct time, thus there is no need for the

It was also found that there was a follow-up write of the, which is why the script wasn't able to make any changes.

Environment variables

  • passwd: password set for user
  • contents of user.conf


These scripts are called before/after a user/reseller/admin is deleted.

Environment variables


These custom scripts are called before/after a user httpd.conf is written.

Environment variables

  • username: owner of httpd.conf file
  • creator: (on domain creation only) reseller who created the user

This script is used for changing the following User info:

  • Name
  • Email
  • language
  • skin

Note that the user.conf may or may not have already been written when this is called, so don't rely on it being written already.

Environment variables

One of the following variables will be set with value of their respective button value:

  • email
  • name
  • language
  • skin

These values are always passed, from the form:

  • nvalue: username
  • evalue: user contact email
  • lvalue: language set
  • skinvalue: name of set skin


These scripts are called before/after the user config file is modified.

Environment variables

  • contents of the user's user.conf...during the pre script, variables may include the same data from the request body.
  • modified_by: reseller who will make/made modifications


These scripts run before/after the DA user's password is changed.

Environment variables

  • contents of user.conf
  • passwd: new password
  • home: user's home directory
  • username: DA name
  • called_by_self(0|1): whether the password change was called by the user themselves
  • options: set to yes if additional settings are passed, which includes:
    • system(no|yes): update user's system (directadmin) password
    • ftp(no|yes): update password used for main ftp account
    • database(no|yes): update password used for main database account


This script is called before/after a user is suspended or unsuspended (activated).

Environment variables

  • contents of user.conf
  • bandwidth_used: network bandwidth used by user
  • quota_used: disk quota used by user
  • choice (0|1): describes the way user was suspended
    • 1 - admin or reseller manually suspended the user The account will not be unsuspended upon the monthly reset.
    • 0 - user was suspended during dataskq tally for bandwidth overuse. account will be unsuspended at the beginning of the month
  • caller_type: type of caller. possible values:
    • 0: N\A
    • 2: reseller
    • 3: admin
  • caller_name: name of admin or reseller who suspended the user


Customizing the php mail log location for your users

This example makes use of the following internal value:


which is unset/missing.

If you add any string, even an empty value like "php_mail_log_dir=", this will be used (don't add an empty value).

This feature allows you to override the /home/user/.php folder to use some other location, in the event your clients have a habit of deleting their logs.

So if you wanted to store them elsewhere, like:


You could use:


Note that DirectAdmin assumes the directory has permission to be created while running as the User.

As such, the parent folder must exist and be controllable by the User ahead of time.

In the above example, this would not be true, so using a hook like:


with the following code:

mkdir -p $D
chown $username:apache $D
chmod 770 $D
exit 0;

would be needed.

Post-cleanup might be required too via this hook:


with this code:

rm -f $D
exit 0;

Make sure to chmod your scripts to 700 and set the ownership to diradmin.

Prevent Users from changing their own DirectAdmin password

There are some cases where you do not want to allow Users to change their passwords, but still allow the passwords to be changed via their creator. I believe WHMCS might be one of these cases, where they'd change their passwords from there.

In DA there are a few ways you could block their access to CMD_PASSWD, but assuming you have 1.51.4+, the simplest would be to create the custom script:


with code:

if [ "$called_by_self" = "1" ]; then
       echo "You cannot change your own password.";
       exit 1;
exit 0;

and chmod the script to 755 and chown to diradmin.

Last Updated: