Persistent permission issue on volume after container restart — JS/CSS assets fail to regenerate

[michnhokn]

Hi, first off thanks for maintaining this image — it's a nice alternative to the older tiredofit/freescout build.

I've run into a recurring issue and wanted to flag it here since issues are disabled.

Symptoms

After restarting the container, the FreeScout UI loads but JavaScript and CSS assets are broken (top menu doesn't work, modals don't open). Browser console / FreeScout logs show errors like:

• File /modules/<modulename>/js/laroute.js does not exist
• File '/www/html/public/storage/js/vars.js' does not exist
• file_put_contents(...storage/framework/cache/data/...): failed to open stream: Permission denied

This matches exactly the Permissions issue documented in the official FreeScout wiki:
https://github.com/freescout-help-desk/freescout/wiki/Installation-Guide#-permissions-issue

The wiki notes that this is "the most common issue" with FreeScout and that it's typically caused by either (a) the web server user not having write permissions on storage/, or (b) a cron task running under a different user than www-data, which then creates cache/build files the web server user can no longer overwrite.

What I'm observing in the container

On first install everything works. After docker restart, ownership of files inside the persistent volume (storage, public/css/builds, public/js/builds, bootstrap/cache) drifts and the php artisan freescout:clear-cache step on boot can no longer regenerate the compiled assets, so JS/CSS stay broken until I manually chown -R inside the container.

Suspected causes (happy to be corrected)

1. The init script may copy source/storage on first boot but skip re-asserting ownership on subsequent restarts.
2. The cron daemon inside the container may be running as a user different from the nginx/php-fpm user, leaving root-owned files behind in storage/framework/cache/data/.
3. UID/GID drift between the named volume and the container's nginx user (similar to the issue the DEBUG_PERMISSIONS flag is designed to surface in nfrastack/container-base).

Questions

1. Where does the source code for this image's Dockerfile and init scripts live? I checked the repo at github.com/nfrastack/container-freescout but I couldn't find the Dockerfile or the cont-init.d scripts there. Are they in a separate repo, a private build pipeline, or am I just missing them?
2. Is there a known workaround / env var (e.g. something like ENABLE_PERMISSIONS_CHECK or matching USER_NGINX to the host UID) that forces ownership to be re-applied on every container start?
3. Has anyone else hit this and found a clean fix beyond shelling in and manually running chown -R?

Happy to help test or open a PR if the Dockerfile source becomes accessible. Thanks!

[michnhokn]

Currently I fix this by setting the entrypoint to /bin/sh and the command to -c sudo chmod -R 775 /data/storage && sudo chown -R nginx:www-data /data/storage && exec /init.

[tiredofit]

Woops - I've turned issues back on for the future. I am familiar with this permissions issue. It caused quite a lot of problems for some with the way I was doing it earlier when setting permissions for the whole folder and it consuming considerable disk/network cycles when one used remote file systems for storage.

For your questions - it's a complex web of upstream images starting from nfrastack/base -> nginx -> nginx-php-fpm -> laravel -> freescout. It helps me keep things orderly for the next phase of things and introduce a level of consistency for the most part. The /container folder holds all the scripts and also some runtime config and data.

• CONTAINER_INIT_POST_FREESCOUT=chmod nginx:www-data /www/freescout theoretically should work executing a command after routing through the image init routines, specifically after the freescout script executes.
• I think I need to fix this up myself once and for all and recreate it. I'll spend an hour diagnosing and see what I can come up with. I'd like to avoid just reintroducing the same problem I created 8 years ago again with this new round.

[tiredofit]

I've updated the upstream laravel routines to do a better job at keeping folder permissions in place. I have a new :latest image that sits on the container registry that supports that change as well as a laravel key issue which could have also been causing some commotion with your modules and cache. How are things looking on your end?