it-roy-ru.com

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

Я новичок в Laravel. Я пытался открыть http://localhost/test/public/, и я получил 

Ошибка в обработчике исключений. 

Я погуглил и изменил разрешение на каталог хранения, используя chmod -R 777 app/storage, но безрезультатно.

Я изменил debug=>true в app.php, посетил страницу и получил ошибку в обработчике исключений: 

Поток или файл "/var/www/html/test/app/storage/logs/laravel.log" не удалось открыть: не удалось открыть поток: в .__ отказано в доступе. /var/www/html/test/bootstrap/compiled.php:8423

Затем я изменил права доступа к каталогу хранения с помощью команды chmod -R 644 app/storage, ошибка «Ошибка в обработчике исключений» исчезла и страница загружена. Но там я получаю это: 

file_put_contents (/var/www/html/laravel/app/storage/meta/services.json): не удалось открыть поток: в доступе отказано

150
vishnub1626

Предложение от 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

ПРИМЕЧАНИЕ: НЕ ДЕЛАЙТЕ ЭТОГО НА ЛЮБОМ УДАЛЕННОМ СЕРВЕРЕ (DEV OR PRODUCTION)

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

302
ecairol

Для googlers, которые сталкивались с этой проблемой с Laravel 5. 

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

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

php -i | grep USER

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

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

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

64
Adriano Rosa

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

mkdir storage/framework/views
41
Hans P

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

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

Sudo chown -R www-data:www-data storage

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

36
RibeiroSt

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

Sudo setenforce 0
29
mahrad

Задача решена 

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

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

18
user3470929

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

(в бродяге) PHP кеш ремесленника: очистить 

(вне бродяги) chmod -R 777 приложение/хранилище 

(в бродяге) композитор дамп-автозагрузка

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

15
Brendan

НИКОГДА НЕ ДАЙТЕ ЕГО РАЗРЕШЕНИЕ 777!

перейдите в каталог проекта laravel на вашем терминале и напишите:

Sudo chown -R your-user:www-data /path/to/your/laravel/project/
Sudo find /same/path/ -type f -exec chmod 664 {} \;
Sudo find /same/path/ -type d -exec chmod 775 {} \;
Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache

Таким образом, вы делаете своего пользователя владельцем и даете привилегии:
1 Выполнить, 2 Написать, 4 Читать
1 + 2 + 4 = 7 означает (RWX)
2 + 4 = 6 означает (rw)
наконец, для доступа к хранилищу, ug + rwx означает, что вы даете пользователю и группе 7

11
Ibrahim W.

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

10
Khay

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

Sudo chmod -R 775 storage

Измените разрешение на загрузочную папку следующим образом

Sudo chmod -R 775 bootstrap/cache

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

8
Koushik Das

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

Sudo chown -R Apache:apache apppath/app/storage
6
Sean

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

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

Смотрите подробное объяснение здесь .

6
ademin

ДЛЯ ЛЮБОГО РАБОТЫ ОС С SELINUX: Правильный способ разрешить httpd писать в папку хранилища laravel:

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

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

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

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

6
Heather Gaye

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

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

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

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

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

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

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

4
KiranD

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

cd /Applications/XAMPP/htdocs  
chmod -R 775 test/app/storage
3
cristianojeda
rm storage/logs/laravel.log  

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

2
aad1992

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

2
Rob L

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

chmod -R 777 bootstrap/cache/
2
malhal

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

1
Den

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

<form method="#" action="#" enctype="multipart/form-data">

Надеется, это поможет где-то как-то ...

0
Vpa

Если кто-то еще сталкивается с подобной проблемой с ошибкой прав доступа к файлу 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

0
Kyle Burkett

У меня была похожая проблема. (Отказано в доступе, в то время как разрешения настроены правильно) с Laravel 5.2 и 5.5

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

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

0
RoDo

Работая в Windows 10 с Laragon и Laravel 4, мне казалось, что невозможно изменить разрешения вручную, поскольку выполнение команд chmod- в терминале Laragon-in-built-Terminal не имеет никакого эффекта.

Однако в этом терминале можно было перейти в папку хранилища и вручную добавить нужные папки следующим образом:

cd app/storage
mkdir cache
mkdir meta
mkdir views
mkdir sessions

Команда cd- в терминале приводит вас к папке (вам может потребоваться изменить этот путь в соответствии с вашей файловой структурой). Команда mkdir- создаст каталог с указанным именем.

У меня не было возможности протестировать этот подход в Laravel 5, но я ожидаю, что подобный подход должен работать.

Конечно, может быть лучший способ, но, по крайней мере, это был разумный обходной путь для моей ситуации (исправление ошибки: file_put_contents(/var/www/html/laravel/app/storage/meta/services.json): failed to open stream).

0
Virginia

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

php artisian serve

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

 enter image description here

0
wajih

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

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

0
Frank

Установка разрешения на 777, безусловно, ужасная идея!

... но

Если вы получаете ошибку разрешения, связанную с папкой «хранилище», вот что сработало для меня:

1) Установите разрешение «Хранилище» и его подпапки на 777 с 

Sudo chmod -R 777 storage/

2) В браузере перейдите на домашнюю страницу laravel laravel/public/(laravel создаст необходимые начальные файлы для хранения)

3) Вернуть безопасное разрешение 775 в хранилище и его подпапки

Sudo chmod -R 775 storage/
0
Nika Tsogiaidze

Эта проблема на самом деле вызвана различными пользователями, которые хотят, чтобы write/read файл, но отказано, вызывают другое право собственности. может быть, вы с правами root установили laravel до того, как войдете на свой сайт как пользователь laravel, где laravel является владельцем по умолчанию, так что это действительно реальная проблема. Таким образом, когда пользователь 'laravel' хочет прочитать/записать весь файл на диске по умолчанию, чтобы ему было отказано, причина в том, что этот файл владеет 'root'.

Для решения этой проблемы вы можете следовать так:

Sudo chown -hR your-user-name /root /nameforlder

или в моем случае

Sudo chown -hR igmcoid /root /sublaravel

Сноска:

  1. root как имя первого владельца, который устанавливал до
  2. your-user-name как владелец по умолчанию, который фактически пишет/читает на сайте.
  3. namefolder как имя папки, в которой вы хотите сменить владельца.
0
Bliss Jaspis

У меня та же проблема при запуске 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 без каких-либо ошибок прав доступа.

0
nigam214