Laravel日志文件写入失败（permission denied）

在讲这个问题之前可能需要简单介绍下Linux系统下的文件的Ownership和Permission。

User是文件的所有者，默认情况下，用户创建了一个文件，该文件的所有者就是该用户。

一个用户组能包含多个用户，所有属于这个组的用户都有相同的权限来访问文件。假设你有一个项目，很多用户都需要访问这个项目文件的权限，你不需要手动赋予这些用户所有权限，你只需要把这些用户加到一个组里面，赋予这些组有访问文件的权限，这样一来就仅仅只有组里面的成员能对文件进行读写操作。

任何其他的用户都能访问文件，因此，给Other用户赋予权限，相当于所有用户都拥有这个权限。

在 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 -e

Laravel中修改创建日志文件的权限：

编辑 confog/logging.php 文件
添加 'permission' => 0664
'daily' => [
        'driver' => 'daily',
        'path' => storage_path('logs/laravel.log'),
        'level' => 'debug',
        'days' => 14,
        'permission' => 0664,
],