Мне пришлось использовать
app/console cache:clear command
для решения проблемы при создании объекта.
Теперь я не могу загрузить свою домашнюю страницу:
http://localhost/projet_etienne/web/app_dev.php
он говорит:
RuntimeException: Не удалось записать файл кэша "/var/www/projet_etienne/app/cache/dev/classes.php".
Я не очень разбираюсь в этом деле кэша!
В моей папке app/cache
я получил папку dev
, dev_new
, a dev_old
. Это нормально?
app/console cache:clear
генерирует, кстати, a:
[ErrorException] Предупреждение: rename (/var/www/projet_etienne/app/cache/dev,/var/www/projet_etien
ne/app/cache/dev_old): каталог не пуст в /var/www/projet _etienne/vendo
г /Symfony/Symfony/SRC/Symfony/Bundle/FrameworkBundle/Command/CacheClearComm
и .php линия 77
Пожалуйста, помогите!
Для хорошего и определенного решения см. раздел Setting up Permissions
в разделе Installing and Configuring Symfony
:
Настройка разрешений
Одной из распространенных проблем при установке Symfony является то, что приложение/кеш и Каталоги приложений/журналов должны быть доступны для записи как веб-сервером, так и пользователь командной строки. В системе UNIX, если пользователь вашего веб-сервера в отличие от пользователя вашей командной строки, вы можете попробовать один из следующие решения.
- Использовать одного и того же пользователя для CLI и веб-сервера
В средах разработки распространенной практикой является использование тех же Пользователь UNIX для CLI и веб-сервера, поскольку он избегает любого из эти разрешения возникают при создании новых проектов. Это может быть сделанные путем изменения конфигурации вашего веб-сервера (например, обычно httpd.conf или apache2.conf для Apache) и установление его пользователя в качестве так же, как и пользователь CLI (например, для Apache, обновить пользователя и группу значения).
- Использование ACL в системе, поддерживающей chmod + a
Многие системы позволяют вам использовать команду chmod + a. Сначала попробуйте это, и если вы получите сообщение об ошибке - попробуйте следующий метод. Для этого используется команда попробуйте определить своего пользователя веб-сервера и установите его как HTTPDUSER:
$ rm -rf app/cache/* $ rm -rf app/logs/* $ HTTPDUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1` $ sudo chmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs $ sudo chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
- Использование ACL в системе, которая не поддерживает chmod + a
Некоторые системы не поддерживают chmod + a, но поддерживают другую утилиту называемый setfacl. Возможно, вам потребуется включить поддержку ACL в вашем разделе и установите setfacl перед его использованием (как в случае с Ubuntu). Эта использует команду, чтобы попытаться определить пользователя веб-сервера и установить его как HTTPDUSER:
$ HTTPDUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1` $ sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs $ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs
Если это не работает, попробуйте добавить параметр -n.
- Без использования ACL
Если ни один из предыдущих методов не работает для вас, измените umask так, чтобы каталоги кэша и журналов будут записываться в группы или записываться в мире (в зависимости, если пользователь веб-сервера и пользователь командной строки находятся в той же группы или нет). Чтобы достичь этого, поместите следующую строку в начало файлов app/console, web/app.php и web/app_dev.php:
umask(0002); // This will let the permissions be 0775 // or umask(0000); // This will let the permissions be 0777
Обратите внимание, что использование ACL рекомендуется, когда у вас есть доступ к ним на вашем сервере потому что изменение umask не является потокобезопасным.
источник: Не удалось записать файл кеша"/var/www/myapp/app/cache/dev/classes.php" при очистке кеша
Скорее всего, это означает, что каталог и/или подкаталоги недоступны для записи. Многие забывают о подкаталогах.
Symfony 2
chmod -R 777 app/cache app/logs
Структура каталогов Symfony 3
chmod -R 777 var/cache var/logs
Разрешения для решения Symfony (упоминалось ранее).
Разрешение для решений Университета KPN - дополнительно включает в себя установку экрана при установке.
Примечание. Если вы используете структуру каталогов Symfony 3, замените app/cache
и app/logs
на var/cache
и var/logs
.
Если папка уже доступна для записи, поэтому это не проблема.
Вы также можете просто перейти к /www/projet_etienne/app/cache/
и вручную удалить папки там (dev, dev_new, dev_old).
Обязательно сохраните копию этой папки где-нибудь, чтобы вернуть ее, если это не устраняет проблему.
Я знаю, что это не так, как должно быть сделано, но это сработало для меня пару раз.
Вероятно, вы прервали clearcache на полпути, и теперь у вас уже есть приложение /cache/dev _old.
Попробуйте это (в корне вашего проекта, если вы находитесь в среде Unixy, такой как OS X или Linux):
rm -rf app/cache/dev*
Возможно, вы забыли изменить разрешения приложения/кэша app/log
Я использую Ubuntu так
sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs
sudo setfacl -dR -m u::rwX app/cache app/logs
Надеюсь, что это поможет.
i выполнено:
ps aux | grep apache
и получил что-то вроде этого:
root 28147 0.0 5.4 326336 27024 ? Ss 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28150 0.0 1.3 326368 6852 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28151 0.0 4.4 329016 22124 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28152 0.1 6.0 331252 30092 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28153 0.0 1.3 326368 6852 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28154 0.0 1.3 326368 6852 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 28157 0.0 1.3 326368 6852 ? S 20:06 0:00 /usr/sbin/apache2 -k start
user 28297 0.0 0.1 15736 924 pts/4 S+ 20:12 0:00 grep --color=auto apache
поэтому мой пользователь без доступа оказался www-data
, поэтому я выполнил команды:
sudo chown -R www-data app/cache
sudo chown -R www-data app/logs
и он решил ошибки доступа.
Никогда не используйте незащищенную 777 для решения конкретных проблем доступа:
sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs
Я перемещаю весь каталог из моей установки Windows на производственный сервер unix, и у меня такая же ошибка. Чтобы исправить это, я просто запустил эти две строки в unix, и все стало нормально работать
rm -rf app/cache/* rm -rf app/logs/*