When working with logrotate under non-root users, you might encounter permission issues when rotating logs owned by different users. The specific scenario occurs when:

• Original log belongs to user 'apache'
• logrotate runs as user 'web'
• Using copytruncate method

The error message clearly indicates the issue:

error: error setting owner of ./logfile.log.1: Operation not permitted

This happens because logrotate attempts to preserve the original file ownership (apache) when creating rotated copies, but the running user (web) doesn't have permission to change file ownership.

Here are several approaches to solve this:

1. Using nocreate Option

Add this to your logrotate configuration:

/var/log/apache/logfile.log {
    copytruncate
    nocreate
    missingok
    rotate 7
    daily
}

The nocreate option prevents logrotate from trying to create new files, avoiding the ownership change attempt.

2. Running as Correct User

The most straightforward solution is to run logrotate as the apache user:

sudo -u apache logrotate /etc/logrotate.conf

3. Using ACLs for Special Permissions

For more complex setups, consider using filesystem ACLs:

setfacl -m u:web:rw /var/log/apache/logfile.log
setfacl -m u:web:rwx /var/log/apache/

Create a post-rotation script that changes ownership after rotation completes:

/var/log/apache/logfile.log {
    copytruncate
    sharedscripts
    postrotate
        chown web:web /var/log/apache/logfile.log.?
    endscript
}

When implementing these solutions:

• Never run logrotate as root unless absolutely necessary
• Consider using systemd timers instead of cron for better isolation
• Audit file permissions regularly
• Use minimal required permissions

---

When running logrotate as a non-privileged user (like 'web') to rotate logs owned by another user (like 'apache'), you'll encounter the ownership preservation behavior that causes permission errors. The key pain point occurs during these phases:

1. Original file: /var/log/app.log (owned by apache:apache)
2. During rotation:
   - Creates /var/log/app.log.1 (attempts to set owner to apache)
   - Fails with "error setting owner" because 'web' lacks chown privileges

Option 1: Use nocreate directive

This prevents logrotate from creating new files during rotation:

/var/log/app.log {
    copytruncate
    nocreate
    missingok
    rotate 7
    daily
}

Option 2: Post-rotation ownership fix

Combine with a postrotate script that changes permissions:

/var/log/app.log {
    copytruncate
    create 0644 web web
    postrotate
        chown apache:apache /var/log/app.log.1 || true
    endscript
}

For more permanent solutions:

# Set ACL to allow 'web' user to manipulate apache-owned files
setfacl -R -m u:web:rwx /var/log/
setfacl -Rd -m u:web:rwx /var/log/

# Or create a dedicated log group
usermod -a -G loggroup web
usermod -a -G loggroup apache
chown -R :loggroup /var/log/
chmod -R g+rw /var/log/

Here's a complete configuration that handles multiple edge cases:

/var/log/webapp/*.log {
    daily
    rotate 30
    copytruncate
    nocreate
    missingok
    compress
    delaycompress
    dateext
    extension .log
    create 0640 web loggroup
    sharedscripts
    postrotate
        # Fix permissions if possible
        [ -f ${1%.log}.1.log ] && chown apache:apache ${1%.log}.1.log
        # Optional: Restart services
        systemctl reload webapp.service >/dev/null 2>&1 || true
    endscript
}

Remember to test configurations with:

logrotate -d /etc/logrotate.d/yourconfig
logrotate -vf /etc/logrotate.d/yourconfig