Logrotate: Permission denied

Logrotate produces the "Permission denied" error when it lacks the filesystem permissions or SELinux context needed to read, rename, or create log files.

When Logrotate Produces This Error

Logrotate displays the "Permission denied" error when it attempts to rotate a log file but the operating system blocks the file operation. The error typically appears in the Logrotate output or in cron job email notifications:

error: error renaming /var/log/myapp/app.log to /var/log/myapp/app.log.1: Permission denied

Logrotate produces this error during manual execution with logrotate -f or during the automated daily cron job. The error prevents rotation for the affected log file while other files may rotate normally.

What Causes the "Permission denied" in Logrotate

SELinux Enforcement Blocks Logrotate

Logrotate encounters "Permission denied" on RHEL, CentOS, Fedora, and other SELinux-enabled systems when log files reside outside the standard /var/log/ directory. SELinux restricts Logrotate to files with the var_log_t security context. Log files in custom directories lack this context, so SELinux denies access even when Unix file permissions are correct.

Incorrect Ownership on the Log Directory

Logrotate fails with "Permission denied" when the parent directory of the log files is owned by a user other than root or the user specified in the su directive. Logrotate needs write access to the parent directory to rename files and create new ones during rotation. A directory owned by a non-matching user or group blocks these operations.

Missing su Directive for Non-Root Log Directories

Logrotate runs as root by default. When log files and their parent directory are owned by a non-root user (e.g., www-data or a dedicated application user), Logrotate may fail because it attempts operations as root in a directory with restricted group permissions. The su directive tells Logrotate to switch to the correct user and group before performing rotation.

World-Writable Parent Directory

Logrotate refuses to process log files in directories with insecure permissions. If the parent directory is world-writable (mode 0777) or writable by a group that is not root, Logrotate reports "Permission denied" as a security precaution. This prevents potential symlink attacks on writable directories.

How to Fix "Permission denied" in Logrotate

1. Check SELinux status on RHEL-based systems. Temporarily set SELinux to permissive mode to determine whether it causes the error:

   getenforce

   If the output is Enforcing, set it to permissive temporarily for testing:

   sudo setenforce 0

   This change is temporary.SELinux returns to enforcing mode after the next reboot. Use this step only for diagnosis.

2. If SELinux is the cause, apply the correct security context to the log directory. Set the var_log_t context so Logrotate can access files:

   sudo semanage fcontext -a -t var_log_t "/var/log/myapp(/.*)?"
   sudo restorecon -Rv /var/log/myapp

   Logrotate can now access files in /var/log/myapp/ with SELinux in enforcing mode.

3. Fix ownership on the log directory and configuration file. Set root ownership on the Logrotate configuration file:

   sudo chown root:root /etc/logrotate.d/{YOUR_APP}
   sudo chmod 644 /etc/logrotate.d/{YOUR_APP}

4. Add the su directive to the Logrotate configuration block when log files are owned by a non-root user. Open the configuration file:

   sudo nano /etc/logrotate.d/{YOUR_APP}

   Add the su directive with the user and group that owns the log directory:

   /var/log/myapp/*.log {
       daily
       rotate 7
       compress
       su myappuser myappgroup
       missingok
       notifempty
   }

5. Fix world-writable directory permissions if the parent directory has overly permissive mode:

   sudo chmod 755 /var/log/myapp

6. Force a rotation to confirm the fix:

   sudo logrotate -vf /etc/logrotate.d/{YOUR_APP}

How to Verify the Fix

Logrotate should complete without "Permission denied" errors. Run Logrotate in verbose mode and check the output:

sudo logrotate -vf /etc/logrotate.d/{YOUR_APP}

Verify that rotated files appear in the log directory:

ls -la /var/log/myapp/

On SELinux-enabled systems, verify the security context:

ls -laZ /var/log/myapp/

Files should show the var_log_t type.

Edge Cases and Variations

Logrotate works with setenforce 0 but fails with SELinux enforcing.Check the audit log for specific SELinux denials:

sudo ausearch -m avc -ts recent | grep logrotate

Use the output to create a targeted SELinux policy module if semanage fcontext alone does not resolve the issue.

Logrotate reports "Permission denied" only for olddir.When the olddir directive points to a directory with different ownership or on a different filesystem, Logrotate cannot move rotated files. Ensure the olddir directory has the same ownership as the log files and resides on the same filesystem.

Logrotate reports "Permission denied" in Docker containers.Container environments may restrict filesystem operations. Verify that the container runs Logrotate with sufficient privileges and that volume mounts have the correct ownership.

Related Logrotate Errors

Logrotate: logs are not rotating-- covers additional causes of rotation failure beyond permission issues.

Logrotate: lines must begin with a keyword or a filename-- a configuration syntax error that prevents Logrotate from reading the configuration file.