Describe the bug

When running the current freshrss/freshrss:latest container, startup takes an extremely long time due to the following line:

Logs (via docker logs --follow --timestamps <container id>):

2025-07-31T03:13:27.908365000Z Enabling module auth_openidc.
2025-07-31T03:25:33.676488000Z [Thu Jul 31 03:25:33.676143 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) configured -- resuming normal operations

Notice the roughly 12 minute gap in the logs between when the entry point runs and when Apache is started. Basically all of that time is spent running the above chown command. This is on a fresh instance with only a single user and a single feed.

To Reproduce

I can reproduce it by running the following docker compose file:

services:
  freshrss:
    image: freshrss/freshrss:latest
    container_name: freshrss
    restart: unless-stopped
    volumes:
      - /data/freshrss/data:/var/www/FreshRSS/data
      - /data/freshrss/extensions:/var/www/FreshRSS/extensions
    ports:
      - 8080:80
    environment:
      CRON_MIN: 2,32
      OIDC_ENABLED: 1
      OIDC_PROVIDER_METADATA_URL: https://<REDACTED>/.well-known/openid-configuration
      OIDC_CLIENT_ID: <REDACTED>
      OIDC_CLIENT_SECRET: <REDACTED>
      OIDC_CLIENT_CRYPTO_KEY: <REDACTED>
      OIDC_REMOTE_USER_CLAIM: preferred_username
      OIDC_SCOPES: openid email profile
      OIDC_X_FORWARDED_HEADERS: X-Forwarded-Host X-Forwarded-Port X-Forwarded-Proto

I also tested the alpine, edge, and edge-alpine tags with the same result (unsurprising since they all run the same startup script).

Expected behavior

I expect the container to start without a long delay.

FreshRSS version

1.26.3

System information

• Database version: SQLite
• PHP version: <managed by docker image>
• Installation type: Docker (latest, alpine, edge, and edge-alpine)
• Web server type: <managed by docker image>
• Device: N/A
• Host OS: Debian 12.10 container running under Proxmox (kernel 6.8.12-1-pve) with nesting enabled so it can run containers within it.
• Host filesystem: ZFS backed by a pool of hard drives
• Browser: N/A

Relevant lines from docker info:

Server:
 Server Version: 28.0.1
 Storage Driver: overlay2
  Backing Filesystem: zfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: true
 Kernel Version: 6.8.12-1-pve
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64

Additional context

chown being slow is a known issue with the overlay2 storage driver when paired with some filesystems/kernels/other. See:

• Recursive chown is really slow docker/for-linux#388
• CHOWN command incredibly slow  linuxserver/docker-bookstack#60

I don't think this issue can be avoided entirely, but there are some potential ways to improve it. The most common recommendation seems to be to use the --chown flag when COPY-ing files into the image wherever possible so only a few directories have the be chown'd at runtime. Here's a random example of doing this that I found linked from the above issue: wizarrrr/wizarr@f68faee