logrotated failing

[nlynzaad]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug
checked my docker log files today and saw the below message being reported for nginx proxy manager:

[7/20/2021] [4:19:25 PM] [Global ] › ✖ error Command failed: logrotate /etc/logrotate.d/nginx-proxy-manager

error: skipping "/data/logs/fallback_access.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.

This seems to be related to the new logrotated development that was done. Reverted to 2.9.4 and issue is resolved.

From a quick google search it seems "su $user $group" needs to be added to the logrotate configuration for the relevant user and groups.

Nginx Proxy Manager Version
Version 2.9.5

To Reproduce
Steps to reproduce the behavior:

1. start nginx proxy manager
2. retrieve docker logs

Expected behavior
docker container user should have rw rights to container without causing the error.

Operating System
Unraid 6.9.2 with Portainer

[chaptergy]

First just FYI: logrotate failing is not a breaking error, it just does not rotate the logs and they work just like they did in v2.9.4.

Which user actually owns the directory on your machine? Not sure if this could be universally implemented that easily if the user is something other than root, since it could be anything. I assumed since npm creates the folder structure and nginx the files it should always be owned by root.

It presumably has something to do with unraid, since on my portainer instance it has been working for weeks. The log files and all parent directories are owned by root and are within a volume.

[nlynzaad]

Thanks for getting back to me so quickly. did a recursive chown on the directory to ensure its set for only root and the error stopped.

Maybe a UID/GID environment variable could work for docker containers but like you mentioned universally this might be an issue.

This seems to have resolved the issue in any case so will resolve the issue.

[five2seven]

This just started happening to me as well, after working flawlessly for months. Nothing has changed in my setup that I'm aware of and I don't know how to fix. Any help would be appreciated.

[chaptergy]

Yeah, logrotate was just added in the latest release, and it crashing due to logrotate is actually an issue for which a PR is already open. See #1250 and #1255.