file_put_contents (meta / services.json): не удалось открыть поток: отказано в разрешении

Предложение от vsmoraes работало для меня:

Laravel >= 5.4

php artisan cache:clear 
chmod -R 777 storage/
composer dump-autoload

Laravel < 5,4

php artisan cache:clear 
chmod -R 777 app/storage 
composer dump-autoload

Для гуглеров, столкнувшихся с этой проблемой с Laravel 5.

Это проблема разрешения, вызванная тем, что разные пользователи пытаются писать в том же файле журнала в папке storage/logs с разными разрешениями.

Что происходит, ваш конфигуратор laravel, вероятно, настроен ежедневно на журнал ошибок, поэтому ваш веб-сервер (apache/nginx) может создать этот файл под пользователем по умолчанию, в зависимости от вашей среды он может быть чем-то вроде _www на OSX или www-data on * NIX, тогда проблема возникает, когда вы, возможно, запускаете некоторые команды artisan и получаете некоторые ошибки, поэтому мастер должен записать этот файл, но с другим пользователем, поскольку PHP на терминале выполняется другим пользователем, фактически вашим пользователем входа, вы можете проверить это, выполнив эту команду:

php -i | grep USER

Если ваш пользователь входа в систему создал этот файл журнала на вашем веб-сервере, вы не сможете писать ошибки в нем, и наоборот, поскольку laravel записывает файлы журнала с разрешениями 655 по умолчанию, который позволяет владельцу писать в нем.

Чтобы исправить это временное действие, вы должны вручную предоставить разрешения для группы 664 для этого файла, чтобы и ваш пользователь входа в систему, и пользователь веб-сервера могли записывать в этот файл журнала.

Чтобы избежать этой проблемы навсегда, вы можете настроить правильные разрешения при создании нового файла в директории storage/logs, наследуя разрешения из каталога на этот ответ https://unix.stackexchange.com/a/115632 может помочь вам справиться с этим.

Для всех, кто использует Laravel 5, Homestead и Mac попробуйте следующее:

mkdir storage/framework/views

несколько раз SELINUX вызвал эту проблему; вы можете отключить selinux с помощью этой команды.

sudo setenforce 0

Проблема решена

php artisan cache:clear
sudo chmod -R 777 vendor storage

это позволяет разрешать запись приложениям, фреймворкам, журналам. Надеюсь, это поможет.

Вы не должны давать 777 разрешений. Это риск для безопасности. Пользователям Ubuntu, в Laravel 5, я стараюсь изменить рекурсивно менять владельца для хранения каталога:

Попробуйте следующее:

sudo chown -R www-data:www-data storage

В системах на основе Ubuntu www-data является пользователем apache.

Для бродячих пользователей решение:

(в бродячих) php artisan cache: clear

(вне бродяг) chmod -R 777 app/storage

(в бродячем) композитор dump-autoload

Убедитесь, что вы chmod в своей локальной среде, а не внутри бродяги, важны здесь!

Если у вас есть Laravel 5 и ищет постоянное решение, применимое как для командной строки php artisan, так и для сервера Apache, используйте это:

sudo chmod -R 777 vendor storage
echo "umask 000" | sudo tee -a /etc/resolv.conf
sudo service apache2 restart

Подробное описание здесь.

Повторите попытку с помощью chmod -R 755 /var/www/html/test/app/storage. Используйте с sudo для Operation not permitted в chmod. Используйте "Проверить разрешение владельца", если все еще есть ошибка.

Предложите правильное разрешение, если для Apache,

sudo chown -R apache:apache apppath/app/storage

ДЛЯ ЛЮБОЙ ОСНОВЫ ОС ОС С SELINUX: правильный способ разрешить httpd записывать в папку хранения laravel:

sudo semanage fcontext -a -t httpd_sys_rw_content '/path/to/www/storage(/.*)?'

Затем немедленно применить изменения:

sudo restorecon -F -r '/path/to/www/storage'

SELinux может быть больно иметь дело, но, если он присутствует, я бы настоятельно советовал вам учиться, а не полностью обходить его.

У меня была такая же проблема, и приведенные ниже шаги помогли мне исправить эту проблему.

• Узнайте пользователя apache - создайте файл test.php в общей папке с кодом

<?php echo exec('whoami'); ?>

И запустите файл из веб-браузера. Это даст пользователю apache. В моем случае это ec2-user, поскольку я использовал aws с cronjob, установленным в /etc/cron.d/. Это может быть другим пользователем для других.

2. Запустите команду ниже в командной строке.

sudo chown -R ec2-user:<usergroup> /app-path/public

Вам нужно определить и использовать правильные "пользовательские" и "пользовательские группы" здесь.

В соответствии с Laravel 5.4, который является последним, поскольку я пишу это, если у вас есть какие-либо проблемы, как это, вы должны изменить разрешение. НЕ СЛУШАЙТЕСЬ К ЛЮБОЙ КТО РАССКАЗЫВАЕТ ВАМ УСТАНОВИТЬ 777 ДЛЯ ЛЮБЫХ КАТАЛОГ. У этого есть проблема безопасности. Измените разрешение папки хранения следующим образом

sudo chmod -R 775 storage

Измените разрешение папки для начальной загрузки

sudo chmod -R 775 bootstrap/cache

Теперь убедитесь, что вы выполняете обе команды из своего каталога приложений. Вы не столкнетесь с проблемами в будущем относительно разрешения. 775 не ставит под угрозу безопасность вашей машины.

rm storage/logs/laravel.log  

решил это для меня

Xampp для использования:

cd /Applications/XAMPP/htdocs  
chmod -R 775 test/app/storage

В любое время, когда я меняю app.php, я получаю разрешение, запрещающее писать bootstrap/cache/services.json, поэтому я сделал это, чтобы исправить его:

chmod -R 777 bootstrap/cache/

После большого количества проб и ошибок с разрешениями каталога у меня закончилось прозрение... на диске не осталось места. Просто хотел поделиться, чтобы убедиться, что никто другой не настолько глуп, чтобы продолжать искать решение в неправильном направлении.

В Linux вы можете использовать df -h, чтобы проверить размер вашего диска и свободное пространство.

У меня была аналогичная проблема. (Разрешение отклонено, а разрешения, если они настроены правильно) с Laravel 5.2 и 5.5

Проблема заключалась в том, что SELinux был включен, что предотвращает использование Apache файлов даже в режиме 777. См. Отвечайте ответ 500 Laravel (Uncaught UnexpectedValueException: Laravel.log) для ответа на вопрос и ответ.

Возможно, это решает проблему и для вас.

У меня такая же проблема при запуске vagrant на mac. решил проблему, изменив пользователя сервера Apache в файле https.conf:

# check user for php
[vagrant] ubuntu ~ $ php -i | grep USER
USER => ubuntu
$_SERVER['USER'] => ubuntu
[vagrant] ubuntu ~ $ 

Запустите apache под пользователем php вместо демон пользователя, чтобы решить проблему с доступом к файлу с помощью php

# change default apache user from daemon to php user
sudo sed -i 's/User daemon/User ubuntu/g' /opt/lampp/etc/httpd.conf
sudo sed -i 's/Group daemon/Group ubuntu/g' /opt/lampp/etc/httpd.conf

теперь, созданный php файл кеша может быть прочитан и отредактирован apache, не показывая никакой ошибки разрешения доступа.

Если вы используете ларадок, попробуйте chown -R laradock:www-data ./storage

Просто запустите свой сервер, используя artisian

php artisian serve

Затем выполните доступ к вашему проекту с указанного URL:

В моем случае решение заключалось в изменении разрешения на каталоги app/storage/framework/views и app/storage/logs.

Если кто-то другой сталкивается с аналогичной проблемой с ошибкой прав доступа fopen, но достаточно разумно, чтобы не слепо chmod 777, вот мое предложение.

Проверьте, какая команда вы используете для разрешений, необходимых Apache:

fopen('filepath/filename.pdf', 'r');

"r" означает открытый только для чтения, и если вы не редактируете файл, это то, что вы должны установить. Это означает, что apache/www-data требует, по крайней мере, разрешения на чтение для этого файла, который, если файл создается через laravel, уже получит разрешение на чтение.

Если по какой-либо причине вы должны записать в файл:

fopen('filepath/filename.pdf', 'r+');

Затем убедитесь, что у apache также есть права на запись в файл.

http://php.net/manual/en/function.fopen.php

Я попытался предоставить 777 доступ к папке хранения, и у меня есть работа для меня

1) перейдите в свой корневой каталог laravel, (/var/www/html для меня) и запустите следующую команду

chmod 777 -R storage

Для LARAVEL 5 попробуйте создать кеш, сеансы и виды в хранилище/фреймворке с разрешением 777.