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

[bwims]

---

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]

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

[STaRDoGG]

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]

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

[bwims]

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]

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]

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]

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]

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]

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 <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AENIQ2JVBRAIGMDAK4YWAMLVTQITLANCNFSM5YTUDNSQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aptalca]

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]

Thanks for all your help!

[bwims]

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

[aptalca]

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]

Okey doke

[MartinX3]

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]

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]

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

[thematrixdev]

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]

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

[CtheCondor]

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]

@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]

@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]

@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]

@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]

@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]

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

[Al4ndil]

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

[Crash1602]

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

[Hogobarth1]

Hi thanks in advance for this great support here!

@aptalca or anyone else who might know are there any news on this issue? I have the same problem here on my system running version: 2.11.0-ls333.
(My system: Geekom MiniAir11 --> OMV (NAS) x64+Docker+Portainer --> Nextcloud with proxy+swag)
My config files are not external and I get the error about once a day.
What would be the best or advised workaround? Reset the container automatically? Per crone job or is there a way to do this in portainer? I do not have Services there.

my stack:

version: "2"
services:
nextcloud:
image: ghcr.io/linuxserver/nextcloud
container_name: nextcloud
environment:
- PUID=1000
- PGID=100
- TZ=Europe/Berlin
volumes:
- /docker-appdata/nextcloud/config:/config
- /docker-appdata/nextcloud/data:/data
depends_on:
- mariadb
restart: unless-stopped
mariadb:
image: ghcr.io/linuxserver/mariadb
container_name: mariadbdb #the double db is on purpose
environment:
- PUID=1000
- PGID=100
- MYSQL_ROOT_PASSWORD=xxxxxxxxxxxxxxx
- TZ=Europe/Berlin
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=xxxxxxxx
- MYSQL_PASSWORD=xxxxxxxxxxx
volumes:
- /docker-appdata/mariadb:/config
restart: unless-stopped
swag:
image: linuxserver/swag
container_name: swag
cap_add:
- NET_ADMIN
environment:
- PUID=1000
- PGID=100
- TZ=Europe/Berlin
- URL=xxxxxxxxxxx.duckdns.org
- SUBDOMAINS=wildcard
- VALIDATION=duckdns
- DUCKDNSTOKEN=xxxxxxxxxxxxxxxxxx
- EMAIL=xxxxxxxxxxx
volumes:
- /docker-appdata/swag:/config
ports:
- 443:443
- 81:80
restart: unless-stopped

[drizuid]

going to go ahead and lock this thread as it's been stated this is an upstream issue with logrotate and not something we can or will spend time on. the "warning" causes no issues with the functioning of the container and is misleading as the file is NOT world readable, it simply has 640 permissions, which logrotate itself is setting, and then complaining about it not being 600.

[drizuid]

new update; it is our fault, we found the cause, we have a proposed solution. digging through logrotate.c was not fun; i apologize for my incorrect info above, we'll have a PR out fixing this soon(tm)