Recursive chown in container entrypoint breaks on read-only volumes

[witten]

First of all, thank you so much for all of your work on Listmonk! I know maintaining an open source project like this isn't easy.

Is your feature request related to a problem? Please describe.

When I attempted to upgrade from the Listmonk 3 container to 4, the recursive chown in entrypoint.sh is erroring (with "Read-only filesystem" for each file accessed). This is because I'm using read-only volumes for both the Listmonk configuration file and static files. That's for security purposes; it's generally best practice to give a container the minimum ability to alter files on the host, just on the off chance the container becomes compromised.

Side note: The chown is also triggering "Operation not permitted" errors on other container files because I'm running the container in rootless Podman, which worked fine with Listmonk 3. I totally understand if this is not a supported use case with Listmonk, but I thought I should mention it as well. (I've tried various permutations of setting PUID and PGID, but that hasn't helped.)

Describe the solution you'd like

I have two ideas for "fixes":

• Instead of unconditionally attempting to chown, maybe just check that files have the correct permissions and error if they don't (without modifying their permissions).
• Or just remove the chown entirely.

[knadh]

Made chown gracefully fail and move on.

There's another minor but annoying that I shipped with v4.0.0 yesterday. Fixing that and will release v4.0.1 shortly.

Edit. That other bug report needs investigation. #2103

[witten]

Thank you! I appreciate the quick fix.

[witten]

FWIW, I can confirm the fix works! Listmonk now runs again with both read-only volumes and rootless Podman.