Cache Permissions not working correctly

[scottcaseproof]

Summary

Our FreeScout install is randomly getting a permissions error on new files for caching as shown here: https://share.cleanshot.com/22xQM9t4

When it occurs I go into the container and run the 'sudo chown -R nginx /www/html' command but it comes back again randomly in the future with a new file name

Steps to reproduce

Setup FreeScout and view the permissions occasionally.

What is the expected correct behavior?

To not need to continually give access to the folder, and for newly created files to get the correct access

Relevant logs and/or screenshots

https://share.cleanshot.com/22xQM9t4

Environment

docker-compse.yml
version: '2'

services:
freescout-app:
image: tiredofit/freescout
container_name: freescout-app
ports:
- 8080:80
links:
- freescout-db
volumes:
### If you want to perform customizations to the source and have access to it, then uncomment this line - This includes modules
- ./data:/www/html
### Or, if you just want to use Stock Freescout and hold onto persistent files like cache and session use this, one or the other.
#- ./data:/data
### If you want to just keep the original source and add additional modules uncomment this line
- ./modules:/www/html/Modules
- ./logs/:/www/logs
env_file:
- .env
environment:
- CONTAINER_NAME="${FREESCOUT_CONTAINER_NAME}"
- DB_HOST="${DB_HOST}"
- DB_NAME="${DB_NAME}"
- DB_USER="${DB_USER}"
- DB_PASS="${DB_PASS}"
- SITE_URL="${SITE_URL}"
- ADMIN_EMAIL="${ADMIN_EMAIL}"
- ADMIN_PASS="${ADMIN_PASS}"
- ENABLE_SSL_PROXY="${ENABLE_SSL_PROXY}"
- DISPLAY_ERRORS="${DISPLAY_ERRORS}"
- TIMEZONE="${TIMEZONE}"
restart: always

freescout-db:
image: tiredofit/mariadb
container_name: freescout-db
volumes:
- ./db:/var/lib/mysql
environment:
- ROOT_PASS="${ROOT_PASS}"
- DB_NAME="${DB_NAME}"
- DB_USER="${DB_USER}"
- DB_PASS="${DB_PASS}"
- CONTAINER_NAME="${MARIADB_CONTAINER_NAME}"
restart: always

freescout-db-backup:
container_name: freescout-db-backup
image: tiredofit/db-backup
links:
- freescout-db
volumes:
- ./dbbackup:/backup
environment:
- CONTAINER_NAME="${BACKUP_CONTAINER_NAME}"
- DB_HOST="${DB_HOST}"
- DB_TYPE="${DB_TYPE}"
- DB_NAME="${DB_NAME}"
- DB_USER="${DB_USER}"
- DB_PASS="${DB_PASS}"
- DB01_BACKUP_INTERVAL="${DB01_BACKUP_INTERVAL}"
- DB01_BACKUP_BEGIN="${DB01_BACKUP_BEGIN}"
- DB_CLEANUP_TIME="${DB_CLEANUP_TIME}"
- COMPRESSION="${COMPRESSION}"
- MD5="${MD5}"
restart: always

networks:
default:
external: true
name: somename

[thomasplevy]

I've narrowed this down to occurring after running freescout updates (not necessarily related to restarting containers)

My update process is as follows:

1. docker compose pull
2. docker compose up -d
3. docker exec -it freescout-app bash -c "cd /www/html && php artisan freescout:after-app-update"

The first two commands, I thought, were responsible for creating the issue but what happens is specifically tied to the freescout:after-app-update command. When executing the command from within the container directories in the data/app/storage/framework/cache directories that are immediately created after the command are owned the root user.

I think my process should be modified to switch user to the nginx user within the container before executing the freescout:after-app-update command, eg:

docker exec -it freescout-app bash -c "sudo su nginx && cd /www/html && php artisan freescout:after-app-update"

I think that would take care of this problem. I haven't had time to test this yet and I'm not sure if this is actually a bug or if it's expected behavior that I simply wasn't expecting.

I'll report back after trying it out next time I run updates.

[tiredofit]

What are you doing that necessitates having to run the after:app-update artisan command? Are you developing with the image or? I have half a dozen installs in use and updates should be seamless from version to version.

There are quite a few undocumented features in this and the base images that allow you to execute commands at certain stage of the container initialization, CONTAINER_POST_INIT_COMMAND=yourcommands shoudl allow you to execute a command. There's also the opportunity to use CONTAINER_POST_INIT_SCRIPT to execute a script thats inside the container via a mapped volume to perform tasks for you.

I don't understand however how this is an issue as your compose.yml looks reasonable. Could it be a host OS or Docker engine issue perhaps?

[thomasplevy]

What are you doing that necessitates having to run the after:app-update artisan command? Are you developing with the image or? I have half a dozen installs in use and updates should be seamless from version to version.

Well nothing specific I guess. Probably just ignorance? Since the after-app-update command runs migration I've added it as part of the update process just in case there's a migration that needs to run against the db with an update.

Though it's occurring to me now that this is maybe an assumption and this isn't necessary? Does part of your image release process take care of migrations so I don't have to ever worry about that when updating?

---

Now that I understand what the core problem is though I think it's probably expected that when I "connect" to the container via docker exec -it freescout-app bash I'm "connecting" as the root user.

$ docker exec -it freescout-app bash -c "whoami"
root

So either:

1. I don't need to run after-app-update at all (cool thank you)
2. I need to switch users before running the command to avoid the inevitable permissions change (I figured it out and sorry for wasting your time)

[thomasplevy]

There are quite a few undocumented features in this and the base images that allow you to execute commands at certain stage of the container initialization, CONTAINER_POST_INIT_COMMAND=yourcommands shoudl allow you to execute a command. There's also the opportunity to use CONTAINER_POST_INIT_SCRIPT to execute a script thats inside the container via a mapped volume to perform tasks for you.

This is good to know and while I think based on the above I probably don't need it now, I may find myself using it in the future. Thank you!

[tiredofit]

OK Glad we got this sorted out. Most of my 120+ images are designed in a way to support seamless upgrades and automatic installs for what I deem as most common use cases. In this one it should just work- I handle all the heavy lifting behind the scenes.

Note, if you are in the shell (docker exec -it bash) just typing artisan will execute it under the correct context and avoid any file permissions issues in future. Failing that, a simple restart of container should reset any permissions that went sideways if by accident you changed some files under root... I hope this helps!

[thomasplevy]

awesome, thanks @tiredofit