--- title: "InterWorx Troubleshooting Guide" source: "https://docs.nexcess.com/hosting/control-panel/interworx/interworx-troubleshooting-guide/" description: "Troubleshoot common InterWorx issues: Fix primary domain changes, DNS, slow panels, email errors, PHP problems, Let's Encrypt, & ModSecurity." vertical: "Hosting" date: "2025-05-29" last_modified: "2026-06-30" --- # InterWorx Troubleshooting Guide 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 `: Specifies the current primary domain. - `--pointer-domain `: Specifies the current pointer domain (if using `--pointer-to-primary`). - `--secondary-domain `: 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:** - **InterWorx 7:** [quad\_daily cron was unable to resolve license.interworx.com (IW7)](https://appendix.interworx.com/current-7/troubleshooting/general/fix-invalid-license-error.html#quad-daily-cron-was-unable-to-resolve-license-interworx-com) - **InterWorx 8:** [quad\_daily cron was unable to resolve license.interworx.com (IW8)](https://appendix.interworx.com/current-8/troubleshooting/general/fix-invalid-license-error.html#quad-daily-cron-was-unable-to-resolve-license-interworx-com) **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,3}' | tr ":" " " > input; default=(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==/default/g" input; while read line; do domain=(echo $line | awk {'print 1'}); version=(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 ``` Options -Indexes ErrorDocument 403 /.noindex.html ``` 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: Apache`Options +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` Options +Indexes ` 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//var//logs/error.log` (for HTTP) - `/home//var//logs/error-ssl.log` (for HTTPS) Replace `` with the SiteWorx account’s system username and `` 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). Bash`vim /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: Bash`service 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//var//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. ---