Search results

The virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual" line is vital to make sure all aspects of mail work within Plesk. If you have commented out that I recommend uncommenting it, restarting postfix and run the repair command again.

Good to read you've found a solution. And thank you for sharing the solution. I am sure this will help other users too.

Can you try to restart postfix service postfix restart and aftwards run plesk repair mail -y one more time? If that does not solve the issue I recommend to open a support ticket for an investigation of the issue on your server. To sign-in to support and open a ticket go to...

Is this domain also the hostname of the server by any chance?

We've updated the article to include a symlink for named-checkzone too. https://support.plesk.com/hc/en-us/articles/12388622047895-Error-is-returned-during-t[…]n-Error-dnsmng-failed-dnsmng-Could-not-start-named-checkconf

Thank you guys for letting us know the workaround does not work for you. We're investigating this further. I will post an update here as soon as we have more information.

You're right. My mistake. Thank you for pointing that out.

Hi there, That fine, it's not necessary to have the host as domain in Plesk. Generally DKIM is not required. But having a SPF and DMARC record are recommended (and required by some providers). So make sure those records exists for hs3.domainname.com. Also make sure that you have rDNS setup...

Hi all, we have identified that this issue only affects Ubuntu 20.04 users and that the issue is related to an update of the bind9-utils package. We are releasing an update tomorrow to fix the issue. In the meantime we've published a workaround solution here...

It's easier to watch the other thread I think. You can click the Watch option above the first post of the thread to be notified if there are any new posts :)

We are investigating the issue. See: Issue - JSON.parse: unexpected non-whitespace character after JSON data at line 1 column 23643 of the JSON data

Hi there, usually when something is blocked at the server side the response error is 403, not 404. Did you look at the domains error logs to see if there are any related errors logged?

From what I can gather CRS rule 920440 blocks a variety of file extensions. Does disabling the rule solve your issue?

No, that's not recommended. You can try to run the repair utility for mail with: plesk repair mail to see if that fixes the issue.

Thank you all for reporting this. Your reports have been really helpful! We are currently investigating this issue with priority. As soon as I have more information on the issue I will post in this thread.

@Précurseur and @MaximilianH do you have DNSSEC enabled on the domain? If not, can check if there are any related errors in the panel.log file (Tools & Settings > Log Browser > Plesk)?

Likely there are duplicated packages in the RPM database. There is a support article which describes a possible solution you can try: https://support.plesk.com/hc/en-us/articles/12377586286615-Yum-fails-to-resolve-dependencies-in-Plesk-for-CentOS-RHEL-package-is-a-duplicate-with

It should not be needed to specifically grand access for the admin user to 127.0.0.1 and ::1. If you are sure the skip-name-resolve option isn't configured but still have this issue I recommend opening a support ticket with out support team for an investigation of the issue on your server. To...

Issue has been confirmed by our engineers and will be fixed in a Plesk future update. The issue can be tracked with ID PPPM-14509 on the change log.

Some other users have reported a "hanged" upgrade process too but found that upgrading actually finished after clicking the Finish button. But if you want to be sure I suggest opening a ticket with our support team for an investigation on you server. To sign-in to support and open a ticket go...