Search our site for answers
Help Docs Control Panel Guides The Ultimate Guide to the InterWorx Control Panel (2025) InterWorx Troubleshooting Guide

InterWorx Troubleshooting Guide

Troubleshoot common InterWorx issues: Fix primary domain changes, DNS, slow panels, email errors, PHP problems, Let's Encrypt, & ModSecurity.
Control Panel InterWorx
28 min read

This guide provides solutions to common issues you might encounter with your InterWorx control panel and related services.

Changing the primary domain name

If you need to change the primary domain associated with your SiteWorx account, follow these steps carefully.

Important Note: This process involves command-line access. If you’re not comfortable with the command line, please contact our support team for assistance.

Step 1: Create a secondary domain

  1. Log in to your SiteWorx account.
  2. Navigate to the domain management section (this might be labeled “Hosting Features” > “Domains” > “Secondary”).
  3. Add the new domain name you want to use as the primary domain as a secondary domain. For example, if your current primary domain is mysite.com and you want to change it to mynewsite.com, add mynewsite.com as a secondary domain.

Step 2: Promote the secondary domain via command line

  1. Connect to your server via SSH.
  2. Run the domain-promoter.pex script with the appropriate flags. The command you’ll use is:
    bash ~iworx/bin/domain-promoter.pex --secondary-to-primary --primary-domain [current_primary_domain] --secondary-domain [new_primary_domain]
    For our example (mysite.com to mynewsite.com), the command would be:
    bash ~iworx/bin/domain-promoter.pex --secondary-to-primary --primary-domain mysite.com --secondary-domain mynewsite.com
  3. The script will handle the necessary changes to make your chosen secondary domain the new primary domain for the account. You can add the --restart-http flag to automatically restart the webserver after the change, or --non-interactive to prevent warnings from pausing the script. Available flags for domain-promoter.pex:
    • --pointer-to-primary: Swaps the primary domain with a pointer domain.
    • --secondary-to-primary: Swaps the primary domain with a secondary domain.
    • --primary-domain <string>: Specifies the current primary domain.
    • --pointer-domain <string>: Specifies the current pointer domain (if using --pointer-to-primary).
    • --secondary-domain <string>: Specifies the current secondary domain (if using --secondary-to-primary).
    • --restart-http: Restarts the webserver (including cluster nodes).
    • --non-interactive: Prevents warnings from pausing the script.
    • --help: Prints the help message.
    • --verbose: Provides verbose output.
    • --no-color: Suppresses colorized output.
    • --force-color: Forces colorized output.

DNS troubleshooting: Fixing SOA and NS records

If your domains aren’t resolving correctly or if DNS zones seem to have incorrect Name Server (NS) records, you might need to correct the SOA (Start of Authority) and NS records.

The following script can help automate this process. You’ll need to provide a list of domains and the correct nameservers.

Script to fix SOA and NS Records:

!/bin/bash

if [[ "#" -lt 4 ]]; then echo "Incorrect usage!" echo 'Correct usage is: fixnameservers.sh "example.com example.net example.org" "ns1.yournameserver.com" "ns1.yournameserver.com" "ns2.yournameserver.com"' echo 'Explained: fixnameservers.sh "list of domains" "SOA nameserver" "first nameserver" "second nameserver"' elif [[ "#" -eq 4 ]]; then
for domain in ${1}; do
#Fix SOA
for soa_id in $(nodeworx -u -c DnsRecord -a listRecordIds | grep "$domain" | grep SOA | awk '{print $1}'); do
nodeworx -u -c DnsRecord -a editSOA -n --record_id ${soa_id} --nameserver "$2" --refresh 7200 --retry 300 --expiration 1209600 --negative_ttl 10800
done
#Fix NS1
for ns1_id in $(nodeworx -u -c DnsRecord -a listRecordIds | grep "$domain" | grep "ns1.liquidweb.com" | grep -v SOA | awk '{print $1}'); do
nodeworx -u -c DnsRecord -a editNS -n --record_id ${ns1_id} --ttl 43200 --nameserver "$3"
done
#Fix NS2
for ns2_id in $(nodeworx -u -c DnsRecord -a listRecordIds | grep "$domain" | grep "ns2.liquidweb.com" | grep -v SOA | awk '{print $1}'); do
nodeworx -u -c DnsRecord -a editNS -n --record_id ${ns2_id} --ttl 43200 --nameserver "$4"
done
done
fi

How to use the script:

  1. Save the script to a file on your server (e.g., fixnameservers.sh).
  2. Make the script executable: chmod +x fixnameservers.sh.
  3. Run the script with your domain(s) and nameservers. For example, if your domains are example.com and example.net, your SOA nameserver is ns1.liquidweb.com, and your primary and secondary nameservers are ns1.liquidweb.com and ns2.liquidweb.com respectively, you would run: Bash./fixnameservers.sh "example.com example.net" "ns1.liquidweb.com" "ns1.liquidweb.com" "ns2.liquidweb.com" Note: The script above is specifically looking for ns1.liquidweb.com and ns2.liquidweb.com to replace. You may need to adjust the grep commands within the script if your current incorrect NS records are different.

SiteWorx email accounts page loads slowly

If the “Email Accounts” page in SiteWorx takes a very long time to load, it’s often because there are many email accounts (e.g., over 100). SiteWorx attempts to display the disk usage for each email account, and calculating this for numerous accounts can be slow.

You can speed up the loading time by disabling the per-account disk usage display.

Steps to disable email account disk usage display:

  1. Connect to your server via SSH.
  2. Open the InterWorx configuration file using a text editor like vim or nano: and run: vim ~iworx/iworx.ini
  3. Look for the line: show_box_size="1"
  4. Change the value from 1 to 0: show_box_size="0"
  5. Save the file and exit the text editor.

The email accounts page in SiteWorx should now load much faster. You will no longer see individual disk usage figures for each email account on that page.

InterWorx panel loads slowly

If your InterWorx panel (NodeWorx or SiteWorx) is taking an unusually long time to load pages, it might be due to the server’s hostname not being correctly listed in the /etc/hosts file.

Fix:

  1. Connect to your server via SSH.
  2. Check your server’s hostname by typing: hostname
  3. Check your server’s main IP address. You can often find this in your welcome email or by using a command like: ip addr show eth0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1 (Replace eth0 if your primary network interface is different).
  4. Open the /etc/hosts file for editing: vim /etc/hosts
  5. Ensure there’s an entry that maps your server’s main IP address to its hostname. If it’s missing or incorrect, add it. Example before:
    • 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 67.225.255.25 migration.5e22a1d5.host.cumawebsitehq.com migration ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  6. Example after (assuming server IP is 64.91.238.156 and hostname is host.cumawebsitehq.com):
    • 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 67.225.255.25 migration.5e22a1d5.host.cumawebsitehq.com migration ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 64.91.238.156 host.cumawebsitehq.com host
    • (Ensure you add your actual server IP and hostname).
  7. Save the file and exit. The panel pages should load more quickly.

InterWorx license “About to Expire” message

If you see a message that your InterWorx license is about to expire, it often means the server couldn’t contact the license server during its routine daily check (the quad_daily cron job). This is usually temporary and resolves itself when the cron runs again.

Official Documentation Links:

To manually resolve:

  1. Connect to your server via SSH.
  2. Stop the NTP (Network Time Protocol) service: service ntpd stop (Or systemctl stop ntpd on newer systems)
  3. Synchronize the server time with the InterWorx NTP server: ntpdate ntp.interworx.com
  4. Start the NTP service: service ntpd start (Or systemctl start ntpd on newer systems)
  5. Manually sync the license: /usr/local/interworx/cron/license.pex --sync

This should resolve the temporary communication issue.

InterWorx stuck in maintenance mode

InterWorx enters maintenance mode during updates. First, check if yum (the package manager) is actively performing an update.

Bash

ps aux | grep yum

If an update is running, wait for it to complete. If no update is in progress and InterWorx remains stuck:

  1. Check for available InterWorx updates: yum update interworx If updates are found, apply them. This might resolve the issue.
  2. Check last upgrade status:
    • Get your InterWorx version: rpm -qi interworx | grep '^Version' Note the version number (e.g., 7.3.0).
    • Check the status of the upgrade for that version: ~iworx/bin/iworx-upgrade.pex --status --version VERSION_NUMBER (Replace VERSION_NUMBER with the actual version).
    • A successful upgrade shows all steps as “complete””: [root@host ~]# ~iworx/bin/iworx-upgrade.pex --status --version 7.3.0 Step Description Status 7057 targeted-restore complete 7067 branding levels complete 7075 eol-centos6 complete 6990 upgrade old le complete 753 mailman complete“
  3. Catch up incomplete upgrade steps: If any steps from the previous command are not “complete”, run: ~iworx/bin/iworx-upgrade.pex --catchup
  4. Check interworx-hotfix Package:
    • See if it’s installed: rpm -q interworx-hotfix
    • If installed, reinstall it: yum reinstall interworx-hotfix
    • If not installed, install it: yum install interworx-hotfix
  5. Restart InterWorx: systemctl restart iworx
  6. Still stuck? If none of these steps resolve the issue, please contact Liquid Web support for further assistance.

PHP version management

PHP Version Matcher (EA4 to InterWorx Migrations)

This script helps set PHP versions for domains based on a source server’s EasyApache 4 configuration, typically used during migrations.

Script:

echo "Source IP:"; read ip; echo "Port:"; read port; ssh root@$ip -p$port cat /etc/userdatadomains | sort | awk '{print NR "- " $1,substr($0,length($0)-4,8)}' | awk '{print$2,<span class="math-inline">3}' | tr ":" " " > input; default=</span>(ssh root@$ip -p$port php -v | grep built | awk {'print $1,$2'} | tr "[:upper:]" "[:lower:]" | tr -d ' ' | tr -d '.' | cut -c1-5); sed -i "s/==0==/<span class="math-inline">default/g" input; while read line; do domain=</span>(echo $line | awk {'print <span class="math-inline">1'}); version=</span>(echo $line | awk {'print $2'}); nodeworx -u -n -c Siteworx -a changePhpVersion --master_domain $domain --php_version=/opt/remi/$version; done < input

How it works (for technical users):

  1. Prompts for the source server IP and SSH port.
  2. Connects to the source server to read domain and PHP version assignments from /etc/userdatadomains.
  3. Determines the default PHP version on the source server.
  4. Creates a local input file mapping domains to their PHP versions (e.g., php74, php80).
  5. Loops through the input file and uses the nodeworx command to set the corresponding PHP version for each domain on the InterWorx server. Assumes PHP versions are installed in /opt/remi/.

Updating all users to a specific PHP version

This is useful if you need to set a uniform PHP version for all SiteWorx accounts, for example, after a migration from a system like EA3 where PHP versions might not match directly.

Command (Example sets all users to PHP 5.4):

Bash

nodeworx -nu --controller SiteWorx --action listAccounts|awk '{print $10}' | xargs -I{} nodeworx -nu --controller SiteWorx --action changePhpVersion --master_domain {} --php-version=/opt/remi/php54
  • Change /opt/remi/php54 to the desired PHP version path (e.g., /opt/remi/php74 for PHP 7.4, /opt/remi/php81 for PHP 8.1). You can see available versions in NodeWorx under “PHP Settings.”

Check current PHP versions for domains:

Bash

nodeworx -nu --controller SiteWorx --action listDomainAccounts|awk '{print $2, $10}'

This command lists each domain and its assigned SiteWorx account (master_domain), which helps identify which PHP version a domain is using via its parent account settings. For per-domain PHP version, you would check SiteWorx.

Accessing InterWorx panel without password (SSO)

If you’ve forgotten your InterWorx (NodeWorx) admin password or the one on file is incorrect, you can generate a Single Sign-On (SSO) URL from the command line to gain access.

  1. Connect to your server via SSH.
  2. Run the following command: printf "nhttps://$(nodeworx -u -c Ip -h -a listIpAddresses |head -1 |awk '{print $1}'):2443/nodeworx/index?action=ssoCommit&sid=$(nodeworx -u -n -c Index -a getSession)nn"
  3. This command will output a URL. Copy this URL and paste it into your web browser.
  4. You should be automatically logged into the NodeWorx control panel. From there, you can reset the admin password if needed via “NodeWorx User Management.”

Unable to access MySQL/MariaDB via CLI (password issue)

If you can’t access MySQL or MariaDB from the command line using the mysql client (e.g., you get an “Access denied” error for root), it might be because the root password isn’t configured correctly or isn’t available to the client.

Fix:

  1. Set/Confirm MySQL Root Password in NodeWorx:
    • Log in to NodeWorx.
    • Navigate to System Services > MySQL Server > Overview.
    • Find the “MySQL root password” section and set or confirm the password. Make a note of this password.
  2. Configure .my.cnf for Root User:
    • Connect to your server via SSH as the root user.
    • Edit (or create if it doesn’t exist) the .my.cnf file in the root user’s home directory: vim /root/.my.cnf
    • Add the following content, replacing $password_you_set_in_first_step with the actual MySQL root password you set or confirmed in NodeWorx: [client] password=$password_you_set_in_first_step user=root
    • Save the file and exit the editor.
    • Set secure permissions for this file: chmod 600 /root/.my.cnf

Now, when you run the mysql command as the root user, it should automatically use these credentials and grant you access.

Transferring cPanel password protected directories to InterWorx

If you’ve migrated a site from cPanel that had password-protected directories (using .htaccess and .htpasswd), you can recreate this protection in InterWorx SiteWorx.

  1. Log in to your SiteWorx Control Panel.
  2. Click on “File Manager” (usually found under the “Hosting Features” section).
  3. Navigate into the directory you want to password protect. You must be inside the directory, not just have it selected in the file list. The path at the top should reflect this: FileMan: root: /your/domain/html/path/to/your/folder
  4. Near the top of the File Manager page, click on “Protect” in the “Tools” menu.
  5. At the bottom of the page, you’ll see a section like: Protect /your/domain/html/path/to/your/folder directory. User name:______ Password:______ Add User
  6. Enter your desired username and password for accessing this directory.
  7. Click “Add User”.

Your directory is now password protected. You can manage users (add more or remove existing ones) from this same “Protect” interface.

Note on migrated files: If you migrated from cPanel, the original .htpasswd file might be in a location like /chroot/home/unixuser/cphomeorig/.htpasswds/public_html/your_protected_folder/passwd. You can use the username(s) from that file when setting up protection in InterWorx if you want to keep the same credentials.

Enabling directory listing (options + indexes)

By default, InterWorx (and Apache) often disables directory listing for security reasons. If you need to allow visitors to see a list of files in a directory when no index file (like index.html or index.php) is present, you need to enable “Indexes”.

However, be aware of a default InterWorx configuration that might override your settings.

The Issue: InterWorx includes a configuration file (often welcome.conf or similar in /etc/httpd/conf.d/) that contains a LocationMatch directive which disables indexes for the root directory and serves a 403 error page instead.

Apache

<LocationMatch "^/+$">
    Options -Indexes
    ErrorDocument 403 /.noindex.html
</LocationMatch>

This directive can prevent Options +Indexes (set in an .htaccess file or a vhost configuration) from working for the main directory of a site.

Solution:

  1. For a specific directory using .htaccess: Create or edit an .htaccess file in the specific directory where you want to enable listing and add: ApacheOptions +Indexes
  2. If .htaccess is overridden by welcome.conf or similar global config: You may need to comment out or adjust the Options -Indexes line within the problematic LocationMatch directive in the server’s Apache configuration files (e.g., in /etc/httpd/conf.d/). Caution: Modifying global Apache configuration files can have wide-ranging effects. If you’re unsure, contact support. It’s generally safer to manage this per-site if possible. One approach is to ensure your per-directory .htaccess is more specific or that AllowOverride options permit this. Alternatively, for a specific vhost, you can add a more specific Directory block in its configuration: Apache<Directory /home/user/[domain.com/html/your-directory](https://domain.com/html/your-directory)> Options +Indexes </Directory> Then restart Apache: service httpd restart or systemctl restart httpd.

Filename redirects not working in .htaccess (REQUEST_FILENAME)

If you’re trying to use .htaccess rules to redirect requests or internally rewrite URLs (e.g., to remove .html extensions), and your conditions using %{REQUEST_FILENAME} aren’t working as expected, InterWorx might require you to be more explicit by prepending %{DOCUMENT_ROOT}.

The Issue: A common rule to remove .html extensions might look like this:

Apache

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^.]+)$ $1.html [NC,L]

This rule checks if the requested filename (without an extension) doesn’t exist as a file, and if so, appends .html. On some InterWorx setups, %{REQUEST_FILENAME} alone might not correctly resolve against the document root of the site.

The Fix: Prepend %{DOCUMENT_ROOT} to %{REQUEST_FILENAME} in your RewriteCond:

Apache

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteRule ^([^.]+)$ $1.html [NC,L]

This ensures that the condition checks against the full path to the file within the website’s document root.

DirectoryIndex updates and 403 Errors

If you’re getting 403 Forbidden errors when trying to access a directory, it might be because the default file Apache looks for (like index.html or index.php) isn’t present, and the server’s DirectoryIndex directive doesn’t include the specific file types you use as directory indexes.

The default InterWorx DirectoryIndex might be too limited.

Solution: You can expand the list of default index files by modifying the Apache configuration.

  1. Connect to your server via SSH.
  2. Run the following commands to update the DirectoryIndex directive in the main Apache configuration and the PHP-FPM configuration:
    • sed -i 's/^DirectoryIndex .*/DirectoryIndex index.php index.php5 index.php4 index.php3 index.perl index.pl index.plx index.ppl index.cgi index.jsp index.jp index.phtml index.shtml index.xhtml index.html index.htm index.wml Default.html Default.htm default.html default.htm home.html home.htm index.js/' /etc/httpd/conf/httpd.conf sed -i 's/^DirectoryIndex .*/DirectoryIndex index.php index.php5 index.php4 index.php3 index.perl index.pl index.plx index.ppl index.cgi index.jsp index.jp index.phtml index.shtml index.xhtml index.html index.htm index.wml Default.html Default.htm default.html default.htm home.html home.htm index.js/' /etc/httpd/conf.d/php-fpm.conf
    • These commands replace the existing DirectoryIndex line with a more comprehensive list.
  3. Restart Apache for the changes to take effect: service httpd restart (Or systemctl restart httpd on newer systems).

Mail issues ✉️

Dovecot: Log file location Dovecot (the IMAP/POP3 server software used by InterWorx) logs its activity to: /var/log/dovecot/dovecot.log

Dovecot cannot write to disk / dotfile errors If you see errors in mail logs related to Dovecot being unable to write files, create lockfiles, or “dotfile” errors, especially during mail transfers or normal operation, Dovecot might have encountered an issue that caused it to set parts of its mail store handling to read-only.

Fix: Often, simply restarting Dovecot can resolve this:

service dovecot restart

(Or systemctl restart dovecot on newer systems).

Dovecot permission errors (vpopmail related) If you see errors in /var/log/dovecot/dovecot.log like:

Error: Mailbox INBOX: file_create_locked(/home/vpopmail/domains/[santanvalley.com/support/Maildir/dovecot-vsize.lock](https://santanvalley.com/support/Maildir/dovecot-vsize.lock)) failed:
safe_mkstemp(/home/vpopmail/domains/[santanvalley.com/support/Maildir/dovecot-vsize.lock](https://santanvalley.com/support/Maildir/dovecot-vsize.lock)) failed: Operation not permitted
Error: fchown(/home/vpopmail/domains/[santanvalley.com/support/Maildir/dovecot-vsize.lockbbc910db75917260](https://santanvalley.com/support/Maildir/dovecot-vsize.lockbbc910db75917260), group=1003(santanva)) failed:
Operation not permitted (egid=104(vchkpw), group based on /home/vpopmail/domains/[santanvalley.com/support/Maildir](https://santanvalley.com/support/Maildir) - see [http://wiki2.dovecot.org/Errors/ChgrpNoPerm](http://wiki2.dovecot.org/Errors/ChgrpNoPerm))

This usually indicates incorrect permissions on the /home/vpopmail directories.

Fix:

  1. Correct the base permissions for vpopmail directories:
    • chmod 755 /home/vpopmail/bin /home/vpopmail/etc /home/vpopmail/include /home/vpopmail/lib
    • chmod 770 /home/vpopmail/domains
  2. Run the InterWorx permissions fix script for all SiteWorx accounts or specific affected accounts:
    • For all accounts: ~iworx/bin/listaccounts.pex --domain | xargs -n1 ~iworx/bin/varpermsfix.pex --siteworx
    • For a specific domain (replace example.com): ~iworx/bin/varpermsfix.pex --siteworx=example.com
    • Alternative loop for all domains (if the above listaccounts.pex method has issues): for i in $(ls /etc/httpd/conf.d/ | grep vhost_ | cut -d_ -f2 | cut -d. -f1,2 | grep -v 000-default); do /usr/local/interworx/bin/varpermsfix.pex --siteworx=$i; done
  3. Restart Dovecot: service dovecot restart

Important note on email client configuration: Customers using InterWorx mail services must use the server’s hostname as the incoming and outgoing mail server in their email clients (e.g., Outlook, Thunderbird, Apple Mail). Using their own domain name (e.g., mail.yourdomain.com if it doesn’t explicitly point to the server hostname with correct SSL) as the mail server may lead to connection or certificate errors.

“Sorry, no mailbox here by that name.” Error (#5.1.1) If incoming mail for an entire domain is being rejected with this error message (visible in mail logs like /var/log/qmail/current or similar), it means qmail (the mail transfer agent) thinks the domain should be delivered locally to a system user, not as a virtual email domain.

Log example: @400000005e1770f22777eb84 delivery XX: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/

Cause: The domain is mistakenly listed in /var/qmail/control/locals. All email domains in SiteWorx are virtual domains and should not be in this file.

Fix:

  1. Connect to your server via SSH.
  2. Check if the affected domain is in /var/qmail/control/locals: Run this command: grep yourdomain.com /var/qmail/control/locals (Replace yourdomain.com with the actual domain name).
  3. If the domain is listed, you need to remove it. Backup the file first: cp /var/qmail/control/locals /var/qmail/control/locals.backup
  4. Edit /var/qmail/control/locals and remove the line containing the problematic domain. vim /var/qmail/control/locals
  5. Save the file.
  6. Qmail should pick up the change automatically, or you can send a HUP signal to qmail-send: killall -HUP qmail-send Or, if qmail is managed by svc (common with InterWorx): svc -h /service/qmail-send

This should correct the mail delivery issue.

ModSecurity issues

ModSecurity is a web application firewall that can sometimes block legitimate requests if they trigger a security rule.

Identifying ModSecurity blocks:

  1. Check the Apache error logs for the specific domain. These are typically located at:
    • /home/<siteworx_user>/var/<domain.com>/logs/error.log (for HTTP)
    • /home/<siteworx_user>/var/<domain.com>/logs/error-ssl.log (for HTTPS) Replace <siteworx_user> with the SiteWorx account’s system username and <domain.com> with the actual domain.
  2. Look for error messages explicitly mentioning “ModSecurity”. These entries often include a rule ID (e.g., [id "xxxxxx"]) and the URI (path) that was blocked (e.g., [uri "/path/to/script.php"]).

403 Error due to HTTP/2.0 and tx.allowed_http_versions

A specific ModSecurity rule can cause 403 errors if a client is using HTTP/2.0 and it’s not listed in the tx.allowed_http_versions variable within the ModSecurity configuration.

Fix:

  1. Connect to your server via SSH.
  2. Edit the Core Rule Set (CRS) configuration file, usually /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf (the exact name might vary slightly). Bashvim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
  3. Find the line that defines tx.allowed_http_versions. It will look something like this: setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1',
  4. Add HTTP/2.0 to the list: setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2.0',
  5. Save the file.
  6. Restart Apache (httpd) and InterWorx: Bashservice httpd restart service iworx restart (Or systemctl restart httpd iworx on newer systems).

PHP: White screen or memory errors

If you encounter a white screen when loading a PHP page, or see errors in your logs like “Allowed memory size of XXXXXX bytes exhausted”, it means a PHP script is trying to use more memory than it’s currently allowed.

Error example: Allowed memory size of 41943040 bytes exhausted (tried to allocate 65536 bytes)

Fix: Increase PHP memory_limit

  1. Identify the PHP version the site is using. You can usually find this in SiteWorx under PHP settings for the domain.
  2. Connect to your server via SSH.
  3. The PHP configuration file (php.ini) location depends on the PHP version and how it was installed. For Remi repository installations (common with InterWorx), it’s typically: /etc/opt/remi/phpXX/php.ini (Replace phpXX with the specific version, e.g., php74, php81). If you’re unsure, you can create a PHP info file (see “PHP Information” section below) to find the “Loaded Configuration File” path.
  4. Open the php.ini file with a text editor: vim /etc/opt/remi/php74/php.ini (Use the correct path for your PHP version).
  5. Search for the memory_limit directive. It will look like: memory_limit = 128M
  6. Increase the value. Common increments are 256M, 512M, 1024M (for 1GB). Don’t set it excessively high without understanding the script’s needs, as this can affect server performance. memory_limit = 256M
  7. Save the file and exit the editor.
  8. Restart PHP-FPM for the changes to take effect. The method depends on the PHP version:
    • For a specific Remi PHP version (e.g., PHP 7.4): systemctl restart php74-php-fpm
    • You can also use the InterWorx PHP-FPM utility: ~iworx/bin/php-fpm.pex --restart-fpm=phpXX (e.g., --restart-fpm=php74) Or to restart all PHP-FPM services and rewrite configs: ~iworx/bin/php-fpm.pex --write-files ~iworx/bin/php-fpm.pex --restart-fpm

WordPress error: “Missing the MySQL extension”

If your WordPress site shows the error: “Your PHP installation appears to be missing the MySQL extension which is required by WordPress,” try these steps:

  1. Ensure MySQL extension is installed for the correct PHP version:
    • Log in to NodeWorx > PHP Settings.
    • Select the PHP version the site is using and check if the mysqlnd (preferred) or mysqli and pdo_mysql extensions are enabled. If not, enable them.
    • Alternatively, from the command line (as root), you can install them if missing. For example, for PHP 7.4 from Remi: yum install php74-php-mysqlnd (Replace php74 with the appropriate version prefix like php56, php80, etc.)
    • After installing/enabling, restart PHP-FPM (see previous section for commands).
  2. Check/Change PHP version:
    • Sometimes, simply switching to a different stable PHP version (e.g., PHP 7.4 or PHP 8.0 if you’re on an older one, or even trying an older one like PHP 5.6 temporarily for testing) can resolve compatibility issues. Do this in SiteWorx for the affected domain.
  3. Verify database credentials:
    • Open your WordPress wp-config.php file (located in the root of your WordPress installation).
    • Note the DB_USER, DB_PASSWORD, and DB_HOST.
    • In SiteWorx, go to Hosting Features > MySQL > Databases.
    • Ensure the database user listed in wp-config.php exists and has the correct password. If you suspect a password mismatch, try updating the MySQL user’s password in SiteWorx to match the one in wp-config.php. Also, ensure the user has the necessary permissions on the database.
    • Sometimes, if the password is too weak or contains problematic special characters, it can cause connection issues. Try setting a strong password.

Let’s Encrypt SSL certificate issues

If Let’s Encrypt SSL certificate generation fails, check the logs for more details.

Log Locations:

  • The primary Let’s Encrypt log in InterWorx can often be found by navigating in SiteWorx to Hosting Features > SSL Certificates > Let’s Encrypt™, and then looking for a “View Log” or similar option if an error occurs.
  • More detailed logs specific to a domain can sometimes be found in: /home/<siteworx_user>/var/<domain.com>/logs/ (Look for files related to Let’s Encrypt or ACME challenges).
  • A general Let’s Encrypt client log might also be at /var/log/letsencrypt/letsencrypt.log.

Common issues and fixes:

1. Permission Denied error: Log shows:

=== 2020-02-14T13:29:29-05:00 ===
sh: /home/interworx/lib/letsencrypt/letsencrypt-auto: Permission denied

Fix:

  • Run the InterWorx CVS permissions fix script: ~iworx/bin/cvspermsfix.pex
  • Verify permissions on the letsencrypt-auto script. They should be 755 (rwxr-xr-x) and owned by root:root: Run this command: ls -la /home/interworx/lib/letsencrypt/letsencrypt-auto The output should be similar to: -rwxr-xr-x 1 root root 80073 Feb 4 19:17 /home/interworx/lib/letsencrypt/letsencrypt-auto If not, set them: chmod 755 /home/interworx/lib/letsencrypt/letsencrypt-auto chown root:root /home/interworx/lib/letsencrypt/letsencrypt-auto

2. certbot: No such file or directory Error: Log shows:

=== 2022-02-16T04:15:53-05:00 ===
sh: /usr/bin/certbot: No such file or directory

Fix: This indicates the Certbot client (used by Let’s Encrypt) is missing or not in the expected path. Reinstalling the Let’s Encrypt plugin in InterWorx usually fixes this.

  • Go to NodeWorx > Plugins.
  • Find the “Let’s Encrypt” plugin and click the Edit (pencil) icon next to it.
  • Select “Disable” from the dropdown menu and click Save.
  • Wait a moment, then click the Edit icon again.
  • Select “Enable” from the dropdown menu and click Save.
  • This process should reinstall necessary files, including Certbot.
  • If the error persists:
    • Ensure the EPEL (Extra Packages for Enterprise Linux) repository is enabled on your server: yum repolist | grep epel If not listed or enabled, install it: yum install epel-release
    • Run a system update: yum update
    • Try disabling and re-enabling the Let’s Encrypt plugin again.

PHP scripts called by HTM/HTML files (security.limit_extensions)

If you have .htm or .html files that are intended to execute PHP code (e.g., using Apache handlers to process HTML files as PHP), you might encounter errors related to security.limit_extensions in PHP-FPM.

Error log example:

[Tue Jul 13 14:09:24 2021] [107.5.254.198] [-:error] [pid 32201:tid 139894791644928] [client 107.5.254.198:0] FastCGI: server "/var/run/a28e1b36-remi-safe-php74.fcgi" stderr: Access to the script '/home/a28e1b36/8ddb04fdcc.nxcli.net/html/index.htm'; has been denied (see security.limit_extensions)

This error means PHP-FPM is configured to only allow execution of files with specific extensions (usually just .php), and your .htm file is being blocked.

Solution (for dedicated/VPS servers where you have root access): Note: For Liquid Web Shared or Cloud hosting, this type of change should typically be handled by system operations. Please contact support.

  1. Identify the SiteWorx user: Determine the system username for the SiteWorx account whose files are affected (e.g., a28e1b36 from the error example).
  2. Create or edit the user’s PHP-FPM configuration file: The file should be located at /etc/fpm-includes/$user.conf, where $user is the SiteWorx system username. vim /etc/fpm-includes/a28e1b36.conf (Replace a28e1b36 with the actual username).
  3. Add the security.limit_extensions Directive: Add the following line to this file, including .htm and .html in the list of allowed extensions: security.limit_extensions = .php .htm .html If the file already contains other settings, add this on a new line. If the security.limit_extensions directive already exists, modify it.
  4. Save the file.
  5. Apply changes and restart PHP-FPM: Use the InterWorx PHP-FPM utility to rewrite configuration files and restart the FPM services: ~iworx/bin/php-fpm.pex --write-files ~iworx/bin/php-fpm.pex --restart-fpm

This will allow PHP-FPM to execute PHP code within .htm and .html files for that specific user.

509 Bandwidth limit exceeded error

When a SiteWorx account exceeds its allocated bandwidth, InterWorx will temporarily suspend the site by changing its DocumentRoot and ScriptAlias in the Apache virtual host configuration to point to an “overage” error page.

Apache configuration snippet (when over bandwidth):

Apache

DocumentRoot /home/interworx/var/errors/overage
ScriptAlias /cgi-bin/ /home/interworx/var/errors/overage/cgi-bin/

If you’ve increased the bandwidth limit for the SiteWorx account in NodeWorx but the site still shows the “509 Bandwidth Limit Exceeded” error, it’s because a cron job checks bandwidth usage periodically. You can force this check to run immediately.

Force bandwidth recalculation:

  1. Connect to your server via SSH.
  2. Switch to the iworx user: su - iworx
  3. Navigate to the InterWorx cron directory: cd /home/interworx/cron
  4. Execute the bandwidth cron script with the --overage flag: ./bandwidth.pex --overage

This command forces a recalculation of bandwidth usage. If the SiteWorx account is now within its new limit, the site should become accessible again shortly (Apache might need a moment to reload its configuration, or you can trigger a graceful restart: service httpd graceful or systemctl graceful httpd).

ImunifyAV UI fails to load

If you encounter issues where the ImunifyAV user interface in InterWorx fails to load, and you see “Problem exists” or similar messages, try the following steps.

  1. Uninstall the ImunifyAV plugin: Connect to your server via SSH and run: ~iworx/bin/imunify.pex --uninstall
  2. Attempt to re-install and check logs: Try reinstalling the plugin: ~iworx/bin/imunify.pex --install --version av Review the installation log for errors: less /home/interworx/var/log/imunify/install.log
  3. Specific error: /home/interworx/plugins/imunifyav/lib is not a directory If the installation log shows a warning like this: [2024-01-27 06:01:54] WARNING: /home/interworx/plugins/imunifyav/lib is not a directory (it should be created by the imunify deploy script). UI will not be installed. This indicates a missing directory that the ImunifyAV installer expects. Fix for Missing lib Directory:
    • If you haven’t already, uninstall the plugin again: ~iworx/bin/imunify.pex --uninstall
    • Manually create the missing lib directory and set its ownership: mkdir -p /home/interworx/plugins/imunifyav/lib chown iworx:iworx /home/interworx/plugins/imunifyav/lib
    • Now, try installing ImunifyAV again: ~iworx/bin/imunify.pex --install --version av

The ImunifyAV UI should now load correctly. If problems persist, check the installation log again for new errors or contact support.

Was this article helpful?