Technical support is available from any of the options below. You must be logged into our client area to open a ticket with the support, billing, and licensing departments.

Priority support is available Monday-Friday from 8:00 am to 5:00 pm MST.
The current local date and time is Sunday - 2019-12-08 05:48 pm MST.




Installation Instructions

Learn how to install the product.

Getting Started

Learn how to configure the product.

Troubleshooting

Having problems? Learn how to diagnose and debug issues.

Knowledgebase

Self help questions and answers for product support, including pre-sales questions.


The AllowSupplementaryGroups option was deprecated in ClamAV 1.00. If this option is present in any of your config files it will display a warning when restarting that service. Just remove the AllowSupplementaryGroups line in the following files:

Centos / RHEL / CloudLinux 7 (systemd)
/etc/clamd.d/scan.conf
/etc/freshclam.conf
/etc/mail/clamav-milter.conf

Centos / RHEL / CloudLinux 6 (sysvinit)
/etc/clamd.conf
/etc/freshclam.conf
/etc/clamav-milter.conf

Debian / Ubuntu
/etc/clamav/clamd.conf
/etc/clamav/freshclam.conf
/etc/clamav/clamav-milter.conf
View Full Article...

Do not use free public DNS servers like Google DNS, OpenDNS or Level3 for nameservers in your servers /etc/resolve.conf as some DNS blacklists and whitelists will block queries from DNS servers issuing what they consider too many queries. This means that some of the tests that SpamAssassin will try to perform will be blocked and non-functional.

If your DNS servers are getting blocked you will also see URIBL_BLOCKED in the Warden spam log when you click on a spam row:

0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: i44hosting.com]
Spamassassin 3.4.0+ allows you to set which DNS servers it will use for DNS lookups. If your DNS servers are getting blocked we recommend that you set non-free DNS servers under:
Warden -> Settings -> Network Settings -> DNS servers
View Full Article...

Many times this error can be fixed by restarting the Plesk panel: /etc/init.d/psa restart Make sure your openssl and curl packages are up to date: // Centos / RHEL yum update openssl curl // Debian / Ubuntu apt-get update openssl curl
You can run the following command to see if your server can connect to the licensing server. You should get a response of Verify return code: 0 (ok) if the connection was successful. openssl s_client -connect www.danami.com:443 If you get the error: openssl s_client -connect www.danami.com:443 - returns: socket: Bad file descriptor connect:errno=9 Make sure that you aren't blocking the licensing server IP addresses: IPv4 198.27.80.6 and IPv6 2607:5300:60:2106:: Imunify360 is known to block our server IPs for some reason.
View Full Article...

No you do not. Roundcube and Horde have plugins to mark messages as junk where the message will be moved into the users Spam folder. Then Plesk has its own spam training script which is run daily to learn off messages in that folder. The task is called "ExecuteSpamtrain". To run the script manually SSH into your server and run as root: plesk daily ExecuteSpamtrain
The actual script that is run: /usr/local/psa/admin/sbin/spamtrain
You can find more information at:
https://support.plesk.com/hc/en-us/articles/115003117405-How-to-train-SpamAssassin
View Full Article...

Symptoms Impossible to send or receive the email on the server. Local delivery does not work. Records like the following can be found in /var/log/maillog Apr 18 22:21:37 youruserver postfix/cleanup[13406]: E96C852200CB: milter-reject: END-OF-MESSAGE from localhost.localdomain[::1]: 4.7.1 Service unavailable - try again later; from=<from@example.com> to=<to@example.com> proto=ESMTP helo=<webmail.example.com> Cause This means that the ClamAV milter is running but cannot connect to the ClamAV daemon to scan the message for viruses so the message is rejected. Resolution
Under Warden -> Settings -> AV Milter Settings -> Change On fail to Accept.  Press the restart button to restart the ClamAV milter. Now email will still be accepted even when ClamAV is having problems (Although it will not be scanned for viruses). Common Problems Not enough memory to start the ClamAV daemon: If you see `Cannot allocate memory` in your ClamAV daemon logs this means that you do not have enough free memory in order to start the ClamAV daemon. Free up some memory on your server or upgrade your system memory then restart the Anti-virus service and Anti-virus milter service. # grep 'Cannot allocate memory' /var/log/clamd.scan Sun Feb 10 03:15:52 2019 -> ERROR: daemonize() failed: Cannot allocate memory Sun Feb 10 03:25:51 2019 -> ERROR: daemonize() failed: Cannot allocate memory Sun Feb 10 03:32:12 2019 -> ERROR: daemonize() failed: Cannot allocate memory Incorrect permissions your /var/tmp or /tmp directories used by the ClamAV and ClamAV Milter: If you see `Failed to create temporary file` in your ClamAV daemon or ClamAV milter logs this means that your /var/tmp or /tmp permissions are not writable by the ClamAV daemon or ClamAV milter. # grep 'Failed to create temporary file' /var/log/clamav-milter.log Thu Apr 18 22:31:55 2019 -> ERROR: Failed to create temporary file Thu Apr 18 22:31:55 2019 -> ERROR: Failed to create temporary file To fix the tmp permissions change the permissions then restart the ClamAV daemon service and ClamAV milter service: chmod 777 /var/tmp /tmp Installation problems: 1. You can re-run the installer on the command line as many times as you like to check for errors. Centos / RHEL / CloudLinux /usr/local/psa/admin/bin/modules/warden/install.sh Debian / Ubuntu /opt/psa/admin/bin/modules/warden/install.sh 2. Try restarting the ClamAV daemon and ClamAV milter services and check for any errors: Centos / RHEL / CloudLinux 7 (systemd) // clamav restart systemctl restart clamd@scan.service // clamav log file tail -f /var/log/clamd.scan // clamav-milter restart systemctl restart clamav-milter.service // clamav-milter log file tail -f /var/log/clamav-milter.log Centos / RHEL / CloudLinux 6 (sysvinit) // clamav restart /etc/init.d/clamd restart // clamav log file tail -f /var/log/clamav/clamd.log // clamav-milter restart /etc/init.d/clamav-milter restart // clamav log file tail -f /var/log/clamav/clamav-milter.log Debian / Ubuntu // clamav restart /etc/init.d/clamav-daemon restart // clamav log file tail -f /var/log/clamav/clamav.log // clamav-milter restart /etc/init.d/clamav-milter restart // clamav log file tail -f /var/log/clamav/clamav-milter.log If you still have problems just open a support ticket in our client area to have an experienced technician diagnose and fix the problem for you.    
View Full Article...

Lots of people seem to be confused by the "autolearn=no" statement in the default X-Spam-Status header. There are usually questions regarding whether or not "no" means SpamAssassin is not autolearning at all. What it actually means is that the specific message which includes the "autolearn=no" part was not autolearned, not that autolearning is disabled or somehow broken.

The three values that can be displayed are "no" (autolearning did not occur), "ham" (the message was learned as ham), and "spam" (the message was learned as spam).

If a message has already been learned by SpamAssassin, then that message will not be learned again. Therefore, if you run a message through SpamAssassin to see why it was classified as spam or ham, and it has already been learned, you will always get the result "autolearn=no". (To see this more clearly, use the "-D" flag, and you will see debug output explaining that the message has already been learned.)

Furthermore, the score used to trigger autolearning is somewhat different than the one reported in the final score; therefore a score displayed in the headers that obstensibly should trigger autolearning will not do so. Again, use the "-D" flag to SpamAssassin, and you will see the score that is used to determine whether or not autolearning will be triggered.

Finally, SpamAssassin requires at least 3 points from the header and 3 points from the body, to auto-learn as spam. If either section contributes fewer points, the message will not be auto-learned.

Possible Autolearn States

ham: the message was learned as ham (non-spam)
spam: the message was learned as spam
no: the specific message didn't achieve the proper threshold values and requirements to be learned
disabled: the configuration specifies bayes_auto_learn 0 or use_bayes 0 and so no autolearning is attempted
failed: autolearning was attempted, but couldn't complete. This happens if SpamAssassin can't gain a lock on the Bayes database files, etc.
unavailable: autolearning not completed for any reason not covered above. It could be the message was already learned.

View Autolearn Score
Warden has a hidden column that can be added to your spam log. Click the column chooser at the bottom of the spam log grid and add the column "Alscore" which contains the actual auto learn score.
View Full Article...

ClamAV will scan inside zip files by default. You can also extend the protection by using the sanesecurity foxhole databases.

The sanesecurity free ClamAV rules will cover this. Take a look at the Foxhole databases specifically

http://sanesecurity.com/foxhole-databases/

How to enable free ClamAV Third Party Signatures

https://docs.danami.com/warden/basics/antivirus-hints



View Full Article...

This can usually be fixed by just restarting the Plesk interface:

/etc/init.d/psa restart
View Full Article...

View All...


Installation Instructions

Learn how to install the product.

Getting Started

Learn how to configure the product.

Troubleshooting

Having problems? Learn how to diagnose and debug issues.

Knowledgebase

Self help questions and answers for product support, including pre-sales questions.


To permanently disable all low level kernel messages (iptables etc) from flooding the console do the following changes (as root):

Edit the file /etc/sysctl.conf Add the following line:
kernel.printk = 4 1 1 7 The above changes will be effective at reboot or immediately using the following command: # /sbin/sysctl -p /etc/sysctl.conf To make the changes only temporarily: # echo "4 1 1 7" > /proc/sys/kernel/printk You can check the current setting with: # cat /proc/sys/kernel/printk
View Full Article...

Juggernaut firewall does support whitelisting fully qualified domain names. To whitelist your IP so you never get blocked by the firewall or login failure daemon:

1. Sign up to a free dynamic DNS service (most home routers support this directly though the router). eg:  http://www.noip.com/remote-access
2. To whiteist your new FQDN on the firewall:  Add your new FQDN you created to: Allow -> Dynamic DNS. Restart the firewall.
3. To whiteist your new FQDN on the login failure daemon: Add your new FQDN you created to: Ignore -> Ignore rDNS. Restart the login failure daemon.

You can set how often the login failure daemon will check the FDQN for IP address changes under Settings -> Block Lists & DynDNS -> Dynamic DNS update interval.

The login failure daemon which checks the DNS resolution of the FQDN then whitelists the ip address in the firewall and ignores any blocks detected from that ip address.
View Full Article...

Many times this error can be fixed by restarting the Plesk panel: /etc/init.d/psa restart Make sure your openssl and curl packages are up to date: // Centos / RHEL yum update openssl curl // Debian / Ubuntu apt-get update openssl curl
You can run the following command to see if your server can connect to the licensing server. You should get a response of Verify return code: 0 (ok) if the connection was successful. openssl s_client -connect www.danami.com:443 If you get the error: openssl s_client -connect www.danami.com:443 - returns: socket: Bad file descriptor connect:errno=9 Make sure that you aren't blocking the licensing server IP addresses: IPv4 198.27.80.6 and IPv6 2607:5300:60:2106:: Imunify360 is known to block our server IPs for some reason.
View Full Article...

Yes we support blocking attacks like these very easily. See the howto for how to enable a custom login failure trigger:
https://docs.danami.com/juggernaut/how-tos/enable-login-failure-triggers
View Full Article...

You can disable and enable the firewall from the command line using the following commands:

To disable the firewall: csf -x To re-enable the firewall: csf -e
View Full Article...

Jugggernaut 2.X
This is fixed in Juggernaut 2.0+. If using Juggernaut 1.X then we recommmend that you upgrade to version 2.

Juggernaut 1.X
1. You might have Plesk internal debugging enabled. Check that debugging is enabled in /usr/local/psa/admin/conf/panel.ini. It is not compatabile with Juggernaut 1.X debugging and should never be used in production so you must disable it.
If the panel.ini file doesn't exist then it could be that you have debugging enabled in the database. You can disable it with the command:

MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -e "replace into misc(param, val) values('debug_util_exec', 'false');" 2. You are blocking Russia on the firewall which blocks Plesks license checks. Plesk changed the license server hostname so we must update it on the firewall.
Disable the firewall on the command line with the command: csf -x Force update the license key with the command: plesk bin license --retrieve Re-enable the firewall with the command: csf -e Whitelist the license check server by logging into Juggernaut and go to Allow -> Allow DynDNS -> Press the advanced button. Change the Plesk license checks entry from ka.odin.com to ka.plesk.com then save and restart the firewall and login failure daemon. Make sure the dynamic dns update interval is set to a reasonable value by going to Block Lists & DynDNS -> DynDNS update interval -> set to 3600 seconds save and restart the firewall and login failure daemon.
View Full Article...

The admin and pro versions of our products are limited to the number of domains you can have in your Plesk panel. If you get this error then it means that you are going over your domain limit. To fix the error you can cancel your current license though our client area then order the 30 domain or unlimited domain licenses. After your order is approved you will get a new license key that you can enter in the license area of the product.
View Full Article...

This error means that your service provider is limiting the amount if iptables rules (numiptent)  that your VPS is allowed to create. Your provider can easily raise this limit using the command below on the hardware note (it can't be run inside your VPS). If your provider refuses to raise this limit then it's time to look for a new service provider as they do not really care about your security. vzctl set CID --numiptent 5000 --save Users using Virtuozzo with a limit set will not be able to use the country or blocklists as they will usually put them over their limit. Users can limit the amount of rules that Juggernaut will create by setting the deny permanently limit and deny temporarily limit under Juggernaut -> Settings -> General Settings. Juggernaut will rotate out older entries to stay under the limit set unless the entry is marked with "do not delete". You can also try to limit the number of iptables rules used for country block lists under Juggernaut -> Settings -> Country Settings -> Ignore CIDR blocks smaller than (set it to something like /24). This will allow you to still block the majority of the country while ignoring the smaller networks. Note
Virtuozzo is not the ideal VPS because it does not support ipset for high performance firewall blocking. Most of the larger VPS providers like OVH, Digital Ocean, and Linode have long switched away from using Virtuozzo and now use KVM which fully supports ipset. Even Virtuozzo themselves have switched over to using KVM in Virtuozzo 7.
View Full Article...

View All...


Installation Instructions

Learn how to install the product.

Getting Started

Learn how to configure the product.

Troubleshooting

Having problems? Learn how to diagnose and debug issues.

Knowledgebase

Self help questions and answers for product support, including pre-sales questions.


1. Double check that the default_monitor_mode is set: Edit /usr/local/maldetect/conf.maldet and find and set: default_monitor_mode="users" 2. Some users may also need to increase their inotify file watch limit on their systems before the maldet monitoring daemon will start. To view your current limit: cat /proc/sys/fs/inotify/max_user_watches To raise your limit: echo fs.inotify.max_user_watches=524288 > /etc/sysctl.d/sentinel.conf
sysctl -p /etc/sysctl.d/sentinel.conf Start the service:

service maldet restart
View Full Article...

No Sentinel Anti-malware is not designed to be an email scanner. Sentinel Anti-malware is designed to scan and monitor your clients web files. The threat landscape in shared hosted environments is unique from that of the standard AV products detection suite in that they are detecting primarily OS level trojans, rootkits and traditional file-infecting viruses but missing the ever increasing variety of malware on the user account level which serves as an attack platform.
View Full Article...

There is a bug in the Linux Malware Detect v1.6.4 daily cron script. You can fix the error by changing line 69 in /etc/cron.daily/maldet From: elif [ $cron_daily_scan == "1" ]; then To: elif [ "$cron_daily_scan" == "1" ]; then
View Full Article...

Plesk recently updated the PHP encoder that they use to protect Plesk extensions and you will get this error if your panel is not fully updated. To fix the error you need to update Plesk to the latest microupdate: To update Plesk though the Plesk Interface  1. In Plesk, go to Tools & Settings and click Updates and Upgrades.
 2. On the Updates and Upgrades page, click Update Components. To update Plesk from the command line (run as root) plesk installer update More information on how to update Plesk
https://support.plesk.com/hc/en-us/articles/213385609-How-to-install-Plesk-updates What Plesk update is currently installed on the system? You can view what version your panel is on the "System Overview" section of your home screen after logging in.  Alternatively, execute the following command in a command-line interface: plesk version At the time this article was written here are the latest updates for each branch:

Plesk Onyx 17.0.17 - Update 76
Plesk Onyx 17.5.3 - Update 83
Plesk Onyx 17.8.11 - Update 68

Plesk Changelog
https://docs.plesk.com/release-notes/onyx/change-log/    
View Full Article...

You can change the interface language under Settings -> Application Settings -> Locale
View Full Article...

View All...