Search results

Glad to hear the issue is sorted. Could you please confirm the configuration of the websites you experienced the issue with prior the migration. More specifically the "Apache & Nginx Settings". When you say served by Apache, I would guess that you mean proxy mode enabled, am I right?

Hi, @dijitul . As per the documentation, there is no option there's no option to use a specific SSL/TLS certificate for mail with Courier, so this is somehow expected:

Hello, @InnoDIGI . Could you please try running the repair utility for the domain affected by the issue: plesk repair mail example.com That should update the Plesk database and SQlite database /var/lib/plesk/mail/outgoing/data.db in case there's some inconsistency.

@InnoDIGI , this appears to be local issue. I am unable to replicate it and there are recent open tickets in our team's processing queue. Have you tried submitting the ticket using another browser? If the issue persists on more than one browser could you please take a screenshot (blurring the...

@MHC_1 , please execute the repair utility for the domain names related to the issue and let us know if it returns any errors: plesk repair mail -v example.com -y

Hello, @mariodieck . Could you please try increasing the timeout and execution period according to this article: https://support.plesk.com/hc/en-us/articles/12377534030871-An-operation-fails-in-Plesk-upstream-timed-out-110-Connection-timed-out-while-reading-response-header-from-upstream Once...

@derchris , could you please run the following command and save the output: sa-learn --dump magic Then move messages to spam or vice versa depending on your situation - re-run the aforementioned command and compare the token count. It is supposed to go up if training is working.

Hello, @ic3_2k . Could you please try manually killing those processes: ps auxf | grep awstats.pl kill PID If the issue reoccurs next time the Awstats process runs, please provide us with the content of /etc/awstats/awstats.model.conf

The behavior was recognized as a bug identified with ID PPPM-15223. At this point, I cannot provide an ETA for the fix. Thank you once again for bringing in to our attention.

It might be a cosmetic bug, but I will need to consult with our team and get back to you. FWIW, the issue is not present on 18.0.74.1, but I assume that you are not ready to upgrade yet. I will follow-up with more details as soon as possible.

Thank you for reporting the issue, @Kaspar . I was able to replicate the behavior and forwarded the case to our developers. I will follow-up with more details as soon as possible.

@Hangover2 is absolutely right, manual OS upgrades haven't been tested by our team yet and therefore are not officially supported. Currently, the recommended path is to migrate to a fresh Debian 13 server. Regarding the experienced issue, I believe the same could be related to the fact that...

The issue was registered as a bug with ID PPP-70078 and it will be fixed in the upcoming Plesk release (18.0.75).

Hello, @Daveo . Have you already tried the repair utility? If not, could you please try: plesk repair web -y

Thank you for the provided details. There is an open case with Imunify regarding the notifications related to outdated WordPress versions/plugin versions and they are currently working on improving the flexibility of notification management. I asked them to check the relation of the...

Hello, @brother4 . Could you please confirm if by excluded you mean the directory has been added into the Imunify's Ignore list? Also, could you please provide an example of the notification(s) you receive for the disabled domain? Thank you in advance.

@jescayola . do you happen to have HTTP/3 support enabled for the domain name in question? If yes, could you please try disabling it for the sake of testing?

The issue was registered as a bug with ID PPP-70078 and it will be fixed in upcoming Plesk release (18.0.75).

You are probably right. Can you please try reproducing the empty error and monitor what's logged into /var/log/plesk/panel.log at that time?

Thank you for the clarification. I misunderstood that the cron remains rather than the system user. I was able to replicate the behavior now. I will double-check with our team and follow-up with more details.