出于明显的安全原因，存储和供应商文件夹的权限应该保持在775。

但是，您的计算机和服务器Apache都需要能够在这些文件夹中进行写操作。例如:当你运行像php artisan这样的命令时，你的计算机需要写入存储中的日志文件。

你所需要做的就是把文件夹的所有权交给Apache:

sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage

然后需要将用户(由用户名引用)添加到服务器Apache所属的组中。像这样:

sudo usermod -a -G www-data userName

注意:通常情况下，组名是www-data，但在您的示例中，将其替换为_www

这招对我很管用:

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

只有当你使用npm (VUE，编译SASS等)时，才添加这个:

sudo chmod -R 777 ./node_modules/

它的作用:

将所有文件权限更改为644 将所有文件夹权限更改为755 对于存储和引导缓存(laravel用于创建和执行文件的特殊文件夹，外部不可用)，将内部所有内容的权限设置为777 对于nodeJS可执行文件，与上面相同

注意:也许你不能，或者不需要，用sudo做前缀。这取决于你的用户权限、组等等。

我已经在EC2实例上安装了laravel，并花了3天的时间来修复权限错误，最终修复了它。 所以我想和其他人分享这段经历。

user problem When I logged in ec2 instance, my username is ec2-user and usergroup is ec2-user. And the website works under of httpd user: apache: apache so we should set the permission for apache. folder and file permission A. folder structure first, you should make sure that you have such folder structure like this under storage storage framework cache sessions views logs The folder structure can be different according to the laravel version you use. my laravel version is 5.2 and you could find the appropriate structure according to your version.

B. permission At first, I see the instructions to set 777 under storage to remove file_put_contents: failed to open stream error. So i setup permission 777 to storage chmod -R 777 storage But the error was not fixed. here, you should consider one: who writes files to storage/ sessions and views. That is not ec2-user, but apache. Yes, right. "apache" user writes file (session file, compiled view file) to the session and view folder. So you should give apache to write permission to these folder. By default: SELinux say the /var/www folder should be read-only by the apache deamon.

因此，我们可以将selinux设置为0: setenforce 0

这可以暂时解决问题，但这使mysql无法工作。 所以这不是一个很好的解。

你可以用以下方法设置一个读写上下文到存储文件夹(记得setenforce 1来测试它)

chcon -Rt httpd_sys_content_rw_t storage/

这样你的问题就解决了。

别忘了这一点 作曲家更新 PHP工匠缓存:清除 这些命令将在之后或之前使用。 我希望你节省时间。 祝你好运。Hacken

修改项目文件夹的权限，允许组内的任何用户(在你的例子中是_www)读/写/执行ec:

chmod -R 775 /path/to/your/project

然后将你的OS X用户名添加到_www组，允许它访问目录:

sudo dseditgroup -o edit -a yourusername -t user _www

bgles发布的解决方案在最初正确设置权限方面对我来说是正确的(我使用第二种方法)，但它对Laravel仍然有潜在的问题。

默认情况下，Apache将创建具有644权限的文件。所以这几乎是存储中的任何东西/。所以，如果你删除了存储/框架/视图的内容，然后通过Apache访问一个页面，你会发现缓存的视图已经创建了，就像:

-rw-r--r-- 1 www-data www-data 1005 Dec  6 09:40 969370d7664df9c5206b90cd7c2c79c2

如果你运行"artisan serve"并访问不同的页面，你将获得不同的权限，因为CLI PHP的行为与Apache不同:

-rw-rw-r-- 1 user     www-data 16191 Dec  6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e

就其本身而言，这没什么大不了的，因为你不会在生产中做这些事情。但是如果Apache创建了一个需要用户写入的文件，它就会失败。这可以应用于缓存文件，缓存视图和日志部署时使用登录用户和工匠。一个简单的例子是“artisan cache:clear”，它将无法删除任何www-data:www-data 644的缓存文件。

这可以部分缓解通过运行手工命令作为www-data，所以你会做/脚本的一切:

sudo -u www-data php artisan cache:clear

或者你可以避免这样做的乏味，并将其添加到你的.bash_aliases:

alias art='sudo -u www-data php artisan'

这已经足够好了，并且不会以任何方式影响安全性。但是在开发机器上，运行测试和卫生脚本会让这个操作变得很麻烦，除非你想设置别名来使用'sudo -u www-data'来运行phpunit和其他任何你检查构建时可能会导致文件创建的东西。

解决方案是遵循bgles建议的第二部分，并在/etc/apache2/envvars中添加以下内容，并重新启动(不重新加载)Apache:

umask 002

This will force Apache to create files as 664 by default. In itself, this can present a security risk. However, on the Laravel environments mostly being discussed here (Homestead, Vagrant, Ubuntu) the web server runs as user www-data under group www-data. So if you do not arbitrarily allow users to join www-data group, there should be no additional risk. If someone manages to break out of the webserver, they have www-data access level anyway so nothing is lost (though that's not the best attitude to have relating to security admittedly). So on production it's relatively safe, and on a single-user development machine, it's just not an issue.

最终，由于您的用户在www-data组中，并且包含这些文件的所有目录都是g+s(文件总是在父目录的组下创建)，用户或www-data创建的任何内容都将是r/w。

这就是我们的目的。

edit

在进一步研究上述设置权限的方法时，它看起来仍然足够好，但一些调整可以有所帮助:

默认情况下，目录是775，文件是664，所有文件的所有者和组都是刚刚安装框架的用户。假设我们从这一点开始。

cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./

我们要做的第一件事是阻止其他所有人的访问，并使组为www-data。只有www-data的所有者和成员才能访问该目录。

sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache

允许web服务器创建服务。如官方Laravel安装指南所建议的那样。设置组粘性位意味着这些将由创建者拥有一组www-data。

find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage

我们对存储文件夹做同样的事情，以允许创建缓存、日志、会话和视图文件。我们使用find显式地为目录和文件设置不同的目录权限。我们不需要在bootstrap/cache中这样做，因为(通常)那里没有任何子目录。

你可能需要重新应用任何可执行标志，删除vendor/*并重新安装composer依赖来为phpunit等重新创建链接，例如:

chmod +x .git/hooks/*
rm vendor/*
composer install -o

就是这样。除了上面解释的Apache的umask，这是所有需要的，而不是使整个项目根可被www-data写入，这是在其他解决方案中发生的事情。因此，这种方式稍微安全一些，因为作为www-data运行的入侵者具有更有限的写访问权限。

最后编辑

Systemd的变化

这适用于php-fpm的使用，但也可能适用于其他应用。

标准的systemd服务需要被覆盖，在override.conf文件中设置umask，并重新启动服务:

sudo systemctl edit php7.0-fpm.service
Use:
    [Service]
    UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service

添加到composer.json

"scripts": {
    "post-install-cmd": [
      "chgrp -R www-data storage bootstrap/cache",
      "chmod -R ug+rwx storage bootstrap/cache"
    ]
}

安装composer后