Search results

Hi Kaspar, Thanks, I will try that. At the moment, I suspect that the blocking could be caused by the “(D)DoS Deflate Interface” extension. I have now whitelisted the IP of the Docker Bridge there and will see if the problem occurs again.

Unfortunately, the issue is not resolved. After removing Imunify and observing stable connectivity for a while, the problem (Gateway Timeout / inaccessible Docker container via subdomain) has returned. Therefore, it seems Imunify was not the root cause. The DROP rule affecting 172.17.0.2...

Update: We’ve now tested completely uninstalling ImunifyAV (and possibly residual components from Imunify360) on our Plesk server. Since then, the recurring DROP rule against 172.17.0.2 has no longer reappeared – and the Docker container remains accessible via subdomains, even without our...

Addition: The problem is not just that a DROP rule exists — that's understandable. The real issue is that any manually added ACCEPT rule (e.g. for 172.17.0.0/16) is automatically removed again, and the Plesk GUI offers no way to make such an exception persistent. This makes it impossible to...

Hi @scsa20, thank you for your reply and for sharing the screenshot. Let me clarify: The port mapping (e.g. 8080:4323) and the Reverse Proxy via domain are both correctly configured — please see the attached screenshots below. The actual issue is not the port mapping or the proxy setup...

Hello everyone, I’m running Plesk Obsidian 18.0.70 on Ubuntu 22.04 and have recently started using Docker (e.g. to host Open WebUI). Since then, I’ve noticed that a DROP rule against 172.17.0.2 (the Docker bridge IP) keeps getting automatically reinserted into the iptables INPUT chain – likely...

Same here: <?xml version="1.0"?> <execution-result log-location="/opt/psa/PMM/sessions/2025-05-17-023003.351/migration.result" local-dump-created="true" export-dump-created="false" local-dump-name="backup_info_2505140230_2505170230.xml"...

I have the same issue - any update on this?

/etc/cron.d/imunify-antivirus

Thanks, this helped :)

Hello Peter, I just found 2 entries in /etc/cron.d: imunify-antivirus and imunify-notifier. Can I delete these entries? imunify-antivirus PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin # Every Saturday at 1:25 25 1 * * 6 root /opt/alt/tmpreaper/usr/sbin/tmpreaper 168...

Hello @jhernanper, no, unfortunately I still get this message by mail on a weekly basis: /bin/sh: line 1: /opt/alt/tmpreaper/usr/sbin/tmpreaper: No such file or directory

Today, once again I received an email saying: /bin/sh: line 1: /opt/alt/tmpreaper/usr/sbin/tmpreaper: No such file or directory

@Kaspar Sorry for my late reply - thank you! I now have the config file :)

Hello @Kaspar, how would I set up such a config file?

Any update on this? # sed -i 's/SHOWWARNING=true/SHOWWARNING=false/' /etc/tmpreaper.conf as described in the link above doesn't work because: sed: can't read /etc/tmpreaper.conf: No such file or directory

I receive this message via e-mail once a week: /bin/sh: line 1: /opt/alt/tmpreaper/usr/sbin/tmpreaper: No such file or directory A while ago I installed Immunify360, uninstalled it and now have ImunifyAV installed. I don't have any /etc/tmpreaper.conf How do I get rid of these e-mails?

Thanks for the information! Yes, I'm running SpamAssassin version 3.4.2, I will wait until the update.

Edit: 1899079.tar.gz is actually not present in the folder /var/lib/spamassassin/3.004002/updates_spamassassin_org/ The folder permissions are set to rwxr-xr-x, group: root, owner: root

There are many lines, maybe these give som hint: Mar 21 05:15:00.109 [14559] dbg: generic: lint check of site pre files succeeded, continuing with channel updates Mar 21 05:15:00.109 [14559] dbg: channel: protocol family available: inet,inet6 Mar 21 05:15:00.109 [14559] dbg: channel: file...