• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue [BUG] Logrotate not work in Plesk Obsidian

Automata

Basic Pleskian
SYSTEM SPECIFICATIONS

Operating system:

Ubuntu 20.04.1 LTS

Plesk version:

Plesk Obsidian v18.0.32_build1800201211.19

Server:
Dedicated server - AMD Ryzen 7 3700X

My logrotate.conf file:
# see "man logrotate" for details
# rotate log files weekly
weekly

# use the adm group by default, since this is the owning group
# of /var/log/syslog.
su root adm

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may be also be configured here.

Hi,

I state that I have already followed your official guide available at this link https://support.plesk.com/hc/en-us/articles/360006381154-Logrotate-cron-task-in-Plesk-fails-skipping-because-parent-directory-has-insecure-permissions and it does not work.

Logrotate doesn't work, in fact if I run this command:

# logrotate -f /etc/logrotate.d/rsyslog

I get these errors:

error: skipping "/var/log/syslog" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.info" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.warn" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.err" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/daemon.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kern.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/auth.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/user.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/lpr.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/cron.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/debug" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/messages" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.


You in your official guide suggest this:

Set the correct permissions and ownerships on the parent directories:

# chmod 755 /var/log/ && chown root:root /var/log/
# chmod 755 /var/log/newrelic && chown root:root /var/log/newrelic
# chmod 755 /var && chown root:root /var

Note: if Ubuntu is used, make sure that su root syslog is included into /etc/logrotate.conf file:

# head /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog

# keep 4 weeks worth of backlogs
rotate 4

I can confirm the problem apparently seems to be solved by using this in the logrotate.conf file configuration:

# use the adm group by default, since this is the owning group
# of /var/log/syslog.
su root adm

or this

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog

The problem is that if you restart the server, Logrotate it doesn't work anymore and always keeps giving the errors that I posted above.

Also if you use these commands that you have indicated in your official guide:


# chmod 755 /var/log/ && chown root:root /var/log/
# chmod 755 /var/log/newrelic && chown root:root /var/log/newrelic
# chmod 755 /var && chown root:root /var

going to Plesk> Tools & Settings> Diagnose & Repair and checking the File System item you have these errors:

The operation failed with the following error: {"id":1,"cmd":"plesk repair fs -n","type":"progress","message":"Checking Linux system files","level":0} {"id":2,"cmd":"plesk repair fs -n","type":"error","message":"There are incorrect permissions on some items: \/var\/log","level":1} {"id":3,"cmd":"plesk repair fs -n","type":"progress","message":"Checking virtual hosts' file system","level":0} {"id":3,"cmd":"plesk repair fs -n","type":"success","message":"Checking virtual hosts' file system","level":0}

And once you click on Repair, Plesk automatically cancels the commands you indicated in your guide:

# chmod 755 /var/log/ && chown root:root /var/log/
# chmod 755 /var/log/newrelic && chown root:root /var/log/newrelic
# chmod 755 /var && chown root:root /var

So I ask someone from the Plesk Support Team to tell me how to solve this problem which is absolutely not up to me but it is a Plesk BUG and how to solve this problem because I have log files of tens and tens of GB and not I would like to fill all my NVME HDD due to this Plesk Bug.

Thanks in advance for the support.

Sincerely, Automata.
 
We use one server that's setup very similar to your own (see forum signature)
FWIW - We had no problems and no errors when we first used the default file; /opt/psa/etc/logrotate.conf.
We've modified the file since inception, but to date, we've had no problems & no errors when using the modified file either (including after any server re-boots).
We get the confirmation lines in /var/log/syslog everyday:
~ data systemd[1]: logrotate.service: Succeeded.
~ data systemd[1]: Finished Rotate log files.
So, it might not be an actual Plesk BUG, it might just be a local misconfiguration?
 
Back
Top