Search results

Thanks, @Kaspar@Plesk, it's working again.

Example: https://<hostname>:8443/modules/plesk-sitejet/index.php/edit/index?dom_id=281&site_id=24128 https://<hostname>:8443/modules/plesk-sitejet/index.php/edit/index?dom_id=281&site_id=2415 Both links create this error response in Plesk: The user says, that before this happened, he had...

# systemctl stop firewalld.service # systemctl disable firewalld

Did you verify the mail server DNS settings with a tool like mxtoolbox.com? Did you verify that the mailboxes exist on the new server? Did you check the maillog what happens when a mail is received?

There are no entries on the "Extension" page? Could you show a screenshot, please?

If "plesk repair all" (which in includes "plesk repair web") doesn't fix it, you'll need to let support look at it.

Either your own server or other servers are bombarding the recipient with emails. For that reason, GMail delays some mails to prevent overloading of the recipient's mailbox. Unless it is your own server that tries to send a large number of mails to that recipient there is nothing you could do...

The log excerpt shown above is just one ordinary SQL injection rule where SQL statements are attached to a URL as parameters. This cannot be triggered by simply opening index.html or index.php. No need to worry. It must be a log entry caused by an external source.

Not with some modifications maybe? https://www.plesk.com/blog/product-technology/avoid-high-cpu-load-block-hackers-bad-bots-effectively/

In this case the error means that the zstd file is not a zstd file. It is either corrupt or it is a regularly packed file in gzip format, but with a wrong extension. If you have uploaded it through FTP, it is also thinkable, that it was not uploaded in binary format, but ASCII format, which...

What's the exact command line you are using to unpack? Did you add the zstd option?

Whatever, but why can't you simply use tar on your server to unpack the backup file? The solution is described in the KB article.

Why not upload the file to the server and use tar to unpack it there?

Yes, it has worked. Thank you.

https://support.plesk.com/hc/en-us/articles/12377533952023-Error-during-statistic-recalculation-on-a-Plesk-server-Cannot-relink-logs-Target-directory-is-in-invalid-state explains what to do to re-create the /logs directory and relink the logs from /var/www/vhosts/system/<domain> to the...

How were you able to determine that the kernel is causing an issue? Maybe it is something else?

No, sorry. I saw it a few days ago in one customer account that was causing a high cpu load, but I don't remember which one that was.

At least it seems that the bot is reading a large number of files that are not related to a website's homepage. It could also be that this is not the real Plesk service, but someone else that spoofs the bot.

Recently I've seen the same behavior on some domains.

In your backup settings: