CentOS 6.4 logrotate show error permission denied

Resolving 'Permission Denied' Errors in CentOS 6.4 Logrotate

Learn how to diagnose and fix common 'Permission Denied' errors encountered when using logrotate on CentOS 6.4 systems, ensuring your logs are managed effectively.

Logrotate is a critical utility in Linux systems, including CentOS 6.4, designed to manage log files automatically. It compresses, archives, and deletes old log files, preventing them from consuming excessive disk space. However, users often encounter 'Permission Denied' errors, which can prevent log files from being rotated, leading to disk space issues and potential system instability. This article will guide you through understanding the common causes of these errors and provide practical solutions to resolve them.

Understanding Logrotate and Permissions

Logrotate operates by executing scripts and commands, often as the root user, to manipulate log files. The 'Permission Denied' error typically arises when logrotate attempts to perform an action (like moving, creating, or deleting a file) on a log file or directory for which it lacks the necessary permissions. This can be due to incorrect file ownership, restrictive directory permissions, or issues with SELinux policies.

flowchart TD
    A[Logrotate Execution] --> B{Check Log File Permissions}
    B -->|Permissions OK| C[Rotate Log File]
    B -->|Permission Denied| D[Error Reported]
    D --> E{Troubleshoot: Ownership, Permissions, SELinux}
    E --> F[Apply Fixes]
    F --> A

Logrotate Permission Error Workflow

Common Causes and Solutions

Identifying the root cause of a 'Permission Denied' error requires checking several aspects of your system's configuration. The most frequent culprits are incorrect file ownership, overly restrictive directory permissions, and SELinux contexts.

1. Incorrect File Ownership and Permissions

Log files are often created by specific services or applications. If logrotate, running as root or another user, tries to modify a file owned by a different user or group, and the permissions don't allow it, a 'Permission Denied' error will occur. Similarly, if the directory containing the log files has restrictive permissions, logrotate might not be able to create new files or move old ones.

ls -l /var/log/your_application/
chown root:root /var/log/your_application/your_log_file.log
chmod 640 /var/log/your_application/your_log_file.log
chmod 755 /var/log/your_application/

Checking and correcting file/directory ownership and permissions.

Ensure that the log files and their parent directories have appropriate ownership and permissions. A common practice is for log files to be owned by root or the service user, with group ownership allowing the service to write to them, and read-only access for others. Directories should typically allow root to create and delete files.

2. SELinux Context Issues

SELinux (Security-Enhanced Linux) provides an additional layer of security by enforcing mandatory access controls. If a log file or directory has an incorrect SELinux context, even if traditional file permissions seem correct, SELinux might prevent logrotate from accessing it. This is a very common cause of 'Permission Denied' errors on CentOS.

ls -Z /var/log/your_application/
chcon -t var_log_t /var/log/your_application/your_log_file.log
restorecon -v /var/log/your_application/

Checking and correcting SELinux contexts for log files.

The ls -Z command shows the SELinux context. Log files typically have a context like var_log_t or a more specific type for a particular service (e.g., httpd_log_t). If the context is incorrect, you can use chcon to temporarily change it or restorecon to restore the default context based on SELinux policy. For permanent changes, you might need to define a new SELinux policy rule using semanage fcontext.

3. Logrotate Configuration Directives

Sometimes, the logrotate configuration itself can contribute to permission issues, especially if create or su directives are used incorrectly. The create directive specifies the permissions and ownership for the new log file that logrotate creates after moving the old one. The su directive allows logrotate to run as a specific user/group for a particular log file.

/var/log/your_application/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root root
    # su your_app_user your_app_group
}

Example logrotate configuration with 'create' directive.

Ensure the create directive specifies permissions and ownership that allow the application to write to the new log file and logrotate to manage it. If your application runs as a non-root user, consider using the su directive to ensure logrotate performs actions with the correct user context, preventing permission conflicts.

1. Identify the Affected Log File

Check /var/log/messages or the output of logrotate -d for the exact log file path causing the 'Permission Denied' error.

2. Check File Ownership and Permissions

Use ls -l <log_file_path> and ls -ld <log_directory_path> to inspect ownership and permissions. Adjust with chown and chmod if necessary.

3. Verify SELinux Context

Run ls -Z <log_file_path> and ls -Zd <log_directory_path>. If contexts are incorrect, use restorecon -v <path> or chcon to fix them. For persistent issues, consider semanage fcontext.

4. Review Logrotate Configuration

Examine the relevant logrotate configuration file (e.g., in /etc/logrotate.d/) for create or su directives that might be misconfigured.

5. Test Logrotate Configuration

Perform a dry run with logrotate -d /etc/logrotate.conf to confirm the issue is resolved before the next scheduled rotation.