error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...

bwims commented 2 years ago

Expected Behavior

normal log output of a healthy running system

Current Behavior

after a number of hours of running, including generating my intial SSL certificate, this error appeared on the log output. I don't know how often it has occurred, how to debug or know whether or not to worry about it.

error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...

Steps to Reproduce

I'm not sure. I have restarted the system and it looks ok so far.

Environment

OS: Dietpi (Debian?) CPU architecture: arm64 How docker service was installed:

container_name: nginx-letsencrypt is running under Portainer

Command used to create docker container (run/create/compose/screenshot)

version: "3.7"
services:
  letsencrypt:
    image: linuxserver/swag
    container_name: nginx-letsencrypt
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - URL=xxxxxxx redacted xxxxxxx
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
      - DUCKDNSTOKEN=xxxxxxx redacted xxxxxxx
      - EMAIL=xxxxxxx redacted xxxxxxx
    volumes:
      - /home/nginx/config:/config
    ports:
      - 443:443
      - 80:80
    restart: unless-stopped
networks:
  default:
    ipam:
      config:
        - subnet: 172.18.0.0/24

Docker logs

error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing... 
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 02-tamper-check: executing... 
[cont-init.d] 02-tamper-check: exited 0.
[cont-init.d] 10-adduser: executing... 
usermod: no changes
-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/
Brought to you by linuxserver.io
-------------------------------------
To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot
To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid:    1000
User gid:    1000
-------------------------------------
[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing... 
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing... 
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing... 
Variables set:

0

0
TZ=Europe/London
URL=xxxxxxx redacted xxxxxxx
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=duckdns
CERTPROVIDER=
DNSPLUGIN=
EMAIL=xxxxxxx redacted xxxxxxx
STAGING=
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for xxxx.duckdns.org will be requested
E-mail address entered: xxxx
duckdns validation is selected
the resulting certificate will only cover the subdomains due to a limitation of duckdns, so it is advised to set the root location to use www.subdomain.duckdns.org
Certificate exists; parameters unchanged; starting nginx
[cont-init.d] 50-config: exited 0.
[cont-init.d] 60-renew: executing... 
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[cont-init.d] 60-renew: exited 0.
[cont-init.d] 70-templates: executing... 
**** The following nginx confs have different version dates than the defaults that are shipped. ****
**** This may be due to user customization or an update to the defaults. ****
**** To update them to the latest defaults shipped within the image, delete these files and restart the container. ****
**** If they are user customized, check the date version at the top and compare to the upstream changelog via the link. ****
/config/nginx/site-confs/default
[cont-init.d] 70-templates: exited 0.
[cont-init.d] 90-custom-folders: executing... 
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-files: executing... 
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-files: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

Server ready

github-actions[bot] commented 2 years ago

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

STaRDoGG commented 2 years ago

Was this solved? I'm getting it as well:

last Monday at 2:00:00 AM error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
last Tuesday at 2:00:00 AM error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
last Wednesday at 2:00:00 AM error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
yesterday at 2:00:00 AM error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...

I tried running:

chmod o-r logrotate.status

which returns no errors, but running this on it's folder still shows that its world readable:

find swag/ -perm -o=r

I'm not too schooled in Linux though, so ....

hugomon commented 2 years ago

I have the same error under Linux raspberrypi 5.15.32-v8+ aarch64

bwims commented 2 years ago

I have found a possible cause.

According to this it could be a matter of changing ownership of the lockfile from [1000,1000] to [root, root]

I know that this points to a Fedora forum, but presumably it is using the same package?

(It's a bit worrying that no one has picked up on this yet...)

aptalca commented 2 years ago

That's not a solution as everything under /config is owned by user abc, not root.

The solution is to fix the permissions of that file so only the user has read permissions and not the group and other, and most importantly find what's changing the permissions in the first place and stop it.

By default the file has the correct permissions. Something on your system is changing it (or perhaps you have your config folder on a remote or mounted share, which we don't support for this reason and others).

I checked multiple test and production instances I manage and they all have the correct permissions for that file.

skyzuma commented 2 years ago

ive also this message and ive changed nothing since weeks ... i think an update from swag is this causing ... and all files are local ...

Operating System: Ubuntu 22.04 LTS Kernel: Linux 5.15.0-1011-raspi Architecture: arm64

bwims commented 2 years ago

Thanks for responding!

Is user abc [1000,1000] ? On my system that is dietpi.

The directory is on the same file system as the docker container, and I haven't done anything to change any protections

Here is a screenshot from winscp

It sounds like you are recommending I remove read permission from group?

aptalca commented 2 years ago

It seems I spoke too soon. I'm now getting it as well, but it's a false positive. In other words, it's a bug with logrotate because the file's permissions are not world readable.

There was a user who had reported the same issue a few weeks ago but in his case the permissions were indeed wrong. I assumed that was the case here as well (my apologies). I can see now that a change in the upstream package is triggering the error even when it's not world readable, but is group readable.

Well push a fix soon, but in the meantime, you can remove the group read perm and the error will go away.

Thanks for letting us know.

bwims commented 2 years ago

Many thanks! One last question, I'm fairly new to docker, will the fix entail a new container pull or anything else?

Thanks again

B

On Mon, 11 Jul 2022 at 13:38, aptalca @.***> wrote:

It seems I spoke too soon. I'm now getting it as well, but it's a false positive. In other words, it's a bug with logrotate because the file's permissions are not world readable.

There was a user who had reported the same issue a few weeks ago but in his case the permissions were indeed wrong. I assumed that was the case here as well (my apologies). I can see now that a change in the upstream package is triggering the error even when it's not world readable, but is group readable.

Well push a fix soon, but in the meantime, you can remove the group read perm and the error will go away.

Thanks for letting us know.

— Reply to this email directly, view it on GitHub https://github.com/linuxserver/docker-swag/issues/240#issuecomment-1180358739, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENIQ2JVBRAIGMDAK4YWAMLVTQITLANCNFSM5YTUDNSQ . You are receiving this because you authored the thread.Message ID: @.***>

aptalca commented 2 years ago

A new image pull (once pushed by us), and then a container recreation. We recommend docker compose, which does it easily: https://docs.linuxserver.io/general/docker-compose

bwims commented 2 years ago

Thanks for all your help!

bwims commented 2 years ago

I know I closed it, but FYI, group read access gets reset the next day!

aptalca commented 2 years ago

It's an upstream issue with logrotate. It erroneously sets the perms of the status file, and then complains about it. Nothing we can do at this point until it's fixed upstream.

bwims commented 2 years ago

Okey doke

MartinX3 commented 2 years ago

For those who may ask. It's still an issue, so we need to chmod 600 /config/log/logrotate.status it as a workaround.

Edit: either it comes back due to a crash and restart or it's useless. I'm still getting this error in my logs.

thematrixdev commented 1 year ago

For those who may ask. It's still an issue, so we need to chmod 600 /config/log/logrotate.status it as a workaround.

It is possible to do the chmod in docker build stage? I worry the permission is reverted from time to time.

aptalca commented 1 year ago

It is logrotate that changes the permissions when it writes to it. Nothing more we can do about it.

thematrixdev commented 1 year ago

It is logrotate that changes the permissions when it writes to it. Nothing more we can do about it.

The built-in Nginx server dies periodically. I have to restart SWAG container afterwards. Is it possible to disable log to avoid this error? Or, does restarting the container daily from host help?

Thanks.

aptalca commented 1 year ago

That's likely not related. Logrotate is a separate service. Nginx service auto starts itself.

CtheCondor commented 1 year ago

I am seeing only

2023-03-19 12:17:01,795 fail2ban.configreader   [399]: WARNING 'allowipv6' not defined in 'Definition'. Using default one: 'auto'

Server ready
error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition.

In my Log for my Docker-compose driven Swag Container and yet I have 2 services that are not accessible through SWAG till I reset them...Daily.. to regain access. the underlying service has not had to be restarted to regain access just SWAG.

Can someone direct me at to more verbose log method to try and resolve this issue? It doesn't appear to be related to the allowip6 Thread nor the logrotate state directly but thats the only log entries I see..

gbytedev commented 1 year ago

@thematrixdev @CtheCondor I had the same issue about having to restart the container every morning. As you mentioned, SWAG was also complaining about fail2ban & logrotate but these were unrelated. The problem was the certificate renewal process failing. Check out this blog post. If you can confirm, we will need to create a new issue.

thematrixdev commented 1 year ago

@thematrixdev @CtheCondor I had the same issue about having to restart the container every morning. As you mentioned, SWAG was also complaining about fail2ban & logrotate but these were unrelated. The problem was the certificate renewal process failing. Check out this blog post. If you can confirm, we will need to create a new issue.

Just several days ago the SSL certificate of a site of my client had expired. Got noticed and complained...

j0nnymoe commented 1 year ago

@thematrixdev @CtheCondor I had the same issue about having to restart the container every morning. As you mentioned, SWAG was also complaining about fail2ban & logrotate but these were unrelated. The problem was the certificate renewal process failing. Check out this blog post. If you can confirm, we will need to create a new issue.

Why not open a new issue anyways with the problem you're having? Fwiw, I too am getting error: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... but it's not stopping my swag containers and this is on 3 different hosts.

thematrixdev commented 1 year ago

@thematrixdev @CtheCondor I had the same issue about having to restart the container every morning. As you mentioned, SWAG was also complaining about fail2ban & logrotate but these were unrelated. The problem was the certificate renewal process failing. Check out this blog post. If you can confirm, we will need to create a new issue.

I have just read the article clearly again. I believe the issue I have met was not due to incorrect configuration on domain names, nor port openening, etc. Should not be due to SSL renewal.

CtheCondor commented 1 year ago

@gbytedev Your direction was spot on in my case but not for the reason I thought. in the /etc/letsencrypt/ folder under renewal I had conf for a domain service I deleted a while back but never connected the dots. I removed the info from the proxy configuration and the site-configs but missed the renewal folder somehow. Thanks!! will see if that resolves everything fully tomorrow as a test.

Enissay commented 1 year ago

Very annoying yet harmless issue. Did anyone report it for a fix upstream ?

Al4ndil commented 9 months ago

Hi I've got the same error for the first time today. Any idea what's causing it?

Crash1602 commented 3 months ago

I also keep getting the error with version 2.11.0-ls312.

warning: state file /config/log/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...

The permissions are set to 0644 every time the container starts. If I manually change them to 0640, they are back to 0644 the next time it starts.

The container itself starts with:

environment:
     - PUID=1000
     - PGID=1000

linuxserver / docker-swag