用过Laravel的小伙伴一开始安装完框架后可能都遇到过daily 日志文件写入失败的问题，接下来我们就来详细说下日志文件写入失败的原因以及对应的解决方案。
在讲这个问题之前可能需要简单介绍下Linux系统下的文件的Ownership和Permission。
- Ownership
- User
User是文件的所有者，默认情况下，用户创建了一个文件，该文件的所有者就是该用户。
- Group
一个用户组能包含多个用户，所有属于这个组的用户都有相同的权限来访问文件。假设你有一个项目，很多用户都需要访问这个项目文件的权限，你不需要手动赋予这些用户所有权限，你只需要把这些用户加到一个组里面，赋予这些组有访问文件的权限，这样一来就仅仅只有组里面的成员能对文件进行读写操作。
- Other
任何其他的用户都能访问文件，因此，给Other用户赋予权限，相当于所有用户都拥有这个权限。
- User
- Permission
在 UNIX/Linux 系统中每一个文件和目录都有3中权限，以下就是对三个所有者的讨论。
- Read：这个权限赋予你打开和读取文件的权限。拥有目录的读权限，你能列出其内容。
- Write：拥有了读权限，你能修改文件的内容。拥有了目录的写权限，你能添加、移除以及重命名该目录下的文件。考虑一种场景，当你拥有文件的写权限，但是没有文件存储目录的写权限，你还是能修改文件的内容，但不能重命名、移动以及移除目录下的文件。
- Execute：在Windows系统中，一个可执行的程序通常都有.exe后缀，你能很方便的运行它。在 UNIX/Linux 中，除非被赋予可执行权限，否则你将不能运行该程序。如果未授权可执行权限，你让然可以看并修改程序代码（被授予读和写权限），但是无法运行它。
linux下文件信息的显示截图
linux下目录的信息显示截图
以上的截图显示了一个文件和文件夹的信息，我们可以看到：
r代表可读，w代表可写，x代表可执行。- 第一位文件显示
-，文件显示d。 - 上面第一张图片，
rw-rw-r-—中。第一组rw-表示文件的所有者对文件有可读、可写、不可执行的权限。第二组rw-表示文件所属的组内用户对该文件有可读、可写、不可执行的权限。第三组r-—表示其他任何用户对该文件有可读、不可写、不可执行的权限。 rw-rw-r--用二进制表示为664，每一位如有权限则为1，否则为0，第一个三位rw-用二进制表示为110转化为十进制就是6，后面两组依次类推，最后得到664。- 上面第一张图片的
dior www-data表示该文件的所有者是dior用户，文件属于www-data组。
我们知道很多应用系统中的日志是写文件的，且是以日期来命名文件的。所以第一次创建日志的用户就显得尤为重要，如果文件创建的 Onwer和 Group 不对，其他的用户触发写入日志文件就会失败。
接下来我们讨论下有多少种不同的用户可能创建日志文件：
Crontab中执行的定时任务，跟创建Crontab的用户有关，此时创建的文件Owner和Group值分别是该用户以及默认的Group。- 一些常驻的后台进程，比如Laravel中的
queue work，此时创建的日志文件Owner和Group值分别是执行该进程的用户以及所属的默认Group。 - 正常用户访问网站产生的日志文件，此时创建的日志文件的
Owner和Group都是www-data，www-data用户是web服务器默认的用户。
由以上的分析，我们大概已经找到了解决问题的方法。
- 执行用户创建日志文件的权限为
664比较恰当，这就需要当前用户的umask为0002。 - 当前执行用户的默认
Group应该设置为www-data。
下面就说下我的具体解决方案：
指定www-data用户执行crontab：
sudo crontab -u www-data -eLaravel中修改创建日志文件的权限：
编辑 confog/logging.php 文件
添加 ‘permission‘ => 0664
'daily' => [
'driver' => 'daily',
'path' => storage_path('logs/laravel.log'),
'level' => 'debug',
'days' => 14,
'permission' => 0664,
],你有什么更好的方法么？欢迎留言！
原文地址：https://www.cnblogs.com/techcoder/p/11371744.html