Last updated on August 21st, 2026 at 01:06 pm
The main lesson: run Laravel commands inside a container as the same operating-system user that runs the web application. Otherwise, the first process that creates a daily log can make it writable only by root.
What I learned
A daily log file is usually created by whichever process writes to it first. If a scheduled task or manual php artisan command runs as root, that process may create the new file as root:root. The normal application user can then fail when it tries to append later.
The timestamp is a clue, not proof that log rotation caused the problem. A file appearing at the same time each day often points to a scheduler, cron entry, queue worker, deployment script, or host command entering the container as root.
How to prevent it
- Run manual commands as the application user.
docker compose exec --user www-data app php artisan your:command - Open routine shells as that user.
docker compose exec --user www-data -it app sh - Set the user for scheduled processes. Configure cron or a process manager so Laravel scheduling and queue commands run as
www-data. - Keep root only for administration. Use it for tasks such as installing packages or repairing permissions, not normal application commands.
Fix existing ownership once
After correcting the process user, repair the writable directories from an administrative shell:
chown -R www-data:www-data storage bootstrap/cache
chmod -R ug+rwX storage bootstrap/cache
Adjust the user and paths for the image. The important part is that the web process, scheduler, queue worker, and routine command-line tasks agree on ownership.
Common mistakes
Cause: entering a container without a user option, which often defaults to root.
Fix: add --user www-data for routine framework commands.
Cause: fixing the symptom with world-writable permissions.
Fix: correct the process user and ownership instead of using chmod 777.
Cause: checking only cron.
Fix: also inspect process-manager configuration, queue workers, deployment scripts, and host-side docker compose exec commands.
Conclusion
Make one concrete change: ensure the next scheduled or manual Laravel command runs as the application user, then confirm the next daily log has matching ownership.
