Laravel Log Permissions: Why a Daily Log Created by deploy Became Unwritable for www-data

A Laravel application can work normally all day and suddenly start failing to write into storage/logs after the date changes.

In ICanUp production, the cause was not Laravel logging itself. The cause was at the Linux level: the same writable directory was being used by processes running as different system users.

Deployment and CLI commands could run as deploy, while HTTP requests through PHP-FPM ran as www-data. If deploy created the new daily log first with mode 0644, www-data could no longer append to it later.

At the application level, the symptom is simple: Laravel tries to append to the daily log file and cannot open it for writing.

If you look only at the Laravel exception, it is easy to start investigating Monolog, channel configuration, or application code.

The first useful check is much simpler: who owns the file, and what are its permissions?

The problematic file conceptually looked like this:

At first glance, the group looks correct: www-data.

But 0644 means only the file owner can write. The group has read permission only.

Neither of these users is inherently wrong. Both have a legitimate role.

The problem appears when a shared resource does not have an explicit permission contract.

For a deploy:www-data file with mode 0644, deploy can write.

PHP-FPM running as www-data receives the group permissions, and the group has no write bit.

A correct group without group write permission is therefore not enough.

Laravel's daily channel creates a new file for a new day.

The previous file may have correct permissions after a manual fix. The next day, however, a deployment or Artisan process running as deploy may be the first process to trigger logging, and the new file can be created with a different mode again.

That is why fixing only the existing file is not enough.

The quickest temptation is:

The error may disappear because everyone can now write.

But the security boundary disappears with it.

• Any local process with access to the system receives more permissions than required.
• It becomes harder to understand which processes are actually supposed to write.
• The next permission problem is hidden instead of fixed.
• Production starts depending on unnecessarily broad filesystem permissions.

For files, the resulting mode is 0664:

Now both the owner deploy and members of the www-data group have write permission.

Mode 2775 on a directory includes the setgid bit.

For a shared directory, this matters because newly created files and subdirectories inherit the directory group instead of depending only on the creating process primary group.

The s in the group permission position indicates that setgid is active.

This solves group inheritance, but it does not by itself guarantee that every new file will be group-writable.

For Laravel's daily channel, I want the file permission for new logs to be explicit.

The logging channel can define that permission directly.

The exact channel configuration depends on the application. The important contract is that a new file should not become writable only by whichever system user happened to create it first.

In addition to Laravel configuration, the umask of processes creating shared files matters.

For a deployment shell, 0002 allows group-shared files to retain group write permission.

This matters when deployment creates more than Laravel logs and those files are later used by other processes in the same group.

I do not use umask 0000. There is no reason to make the files writable by everyone.

After changing permissions, looking at ls -l is not enough. I want to verify access as the actual production users.

If a daily log already exists, I check that file separately too:

A correctly configured file still cannot be reached if one of its parent directories blocks traversal for the process.

This is the most important part of verification.

If I repaired only the current file, the problem can return the next day. The fix is proven only when the next new daily log automatically receives the correct group and mode 0664.

After this incident, I stopped treating storage permissions as a one-time setup step performed during the first deployment.

They are part of the production contract between multiple processes.

• deploy has explicitly defined permissions.
• www-data has explicitly defined permissions.
• Shared writable directories use a shared group.
• Directories use setgid where group inheritance is required.
• New files are created with group write permission.
• Deployment does not repair permission problems with 777.
• Verification covers future files, not only current ones.

This is also why I prefer production deployment to be reproducible instead of becoming a collection of manual server fixes. I described the broader process in my article about a real Laravel CI/CD pipeline.

• Do not use chmod -R 777 storage as a permanent fix.
• Do not repair one current log file and consider the problem solved.
• Do not run PHP-FPM as root to bypass permission problems.
• Do not run application commands through sudo without considering which files they create.
• Do not rely on the correct group without group write permission.
• Do not rely on 0664 alone if future files can inherit the wrong group.
• Do not test access only as my own SSH user.

• Identify every system user that can write Laravel logs.
• Inspect owner, group, and mode with stat.
• Verify the PHP-FPM user.
• Use a shared group for processes that genuinely need write access.
• Set setgid on the shared writable directory.
• Use 0664 for log files when the group needs write access.
• Verify Laravel daily channel permissions.
• Verify a compatible umask for processes creating shared files.
• Test the directory and file as both deploy and www-data.
• Repeat the verification after a new daily log has been created.

The Laravel log failure in ICanUp production turned out to be a classic conflict between multiple system users.

deploy could create the new daily log first. The file had the www-data group, but mode 0644 gave that group read permission only. When PHP-FPM running as www-data tried to append the next message, it received Permission denied.

A one-time chmod only repairs the current file. 777 simply removes the access boundary.

The stable fix combines several pieces: a shared group, setgid on the directory, 0664 for log files, a compatible umask, and verification from each real production user.

My main lesson is that permissions for shared runtime files need to be designed as explicitly as database credentials, queue workers, or deployment flow.