symfony2 : 캐시 디렉토리를 쓰지 못했습니다.

symfony2 : 캐시 디렉토리를 쓰지 못했습니다.

---

나는 사용해야 만했다

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, a dev_new, dev_old폴더가 있습니다. 정상인가요?

그만큼

app/console cache:clear

방법으로 생성 :

[ErrorException] 경고 : rename (/ var / www / projet_etienne / app / cache / dev, / var / www / projet_etien
ne / app / cache / dev_old) : / var / www / projet_etienne / vendo
r / symfony의 디렉토리가 비어 있지 않습니다. / symfony / src / Symfony / Bundle / FrameworkBundle / Command / CacheClearComm
and.php line 77

도와주세요!

---

양호하고 확실한 솔루션은 Setting up Permissions섹션 의 섹션을 Installing and Configuring Symfony참조하십시오.

권한 설정

Symfony를 설치할 때 흔히 발생하는 문제 중 하나는 웹 서버와 명령 줄 사용자가 모두 app / cache 및 app / logs 디렉토리를 쓸 수 있어야한다는 것입니다. UNIX 시스템에서 웹 서버 사용자가 명령 줄 사용자와 다른 경우 다음 솔루션 중 하나를 시도 할 수 있습니다.

1. CLI 및 웹 서버에 동일한 사용자 사용

개발 환경에서는 새 프로젝트를 설정할 때 이러한 권한 문제를 방지하기 때문에 CLI 및 웹 서버에 동일한 UNIX 사용자를 사용하는 것이 일반적입니다. 웹 서버 구성 (예 : Apache의 경우 일반적으로 httpd.conf 또는 apache2.conf)을 편집하고 해당 사용자를 CLI 사용자와 동일하게 설정하여 수행 할 수 있습니다 (예 : Apache의 경우 사용자 및 그룹 값 업데이트).

2. chmod + a를 지원하는 시스템에서 ACL 사용

많은 시스템에서 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

3. chmod + a를 지원하지 않는 시스템에서 ACL 사용

일부 시스템은 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

Symfony 3의 경우 다음과 같습니다.

$ 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 var/cache var/logs
$ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX var/cache var/logs

이것이 작동하지 않으면 -n 옵션을 추가해보십시오.

4. 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

umask 변경은 스레드로부터 안전하지 않으므로 서버에서 ACL에 액세스 할 수있는 경우 ACL을 사용하는 것이 좋습니다.

http://symfony.com/doc/current/book/installation.html#checking-symfony-application-configuration-and-setup

소스 : 캐시를 지울 때 "/var/www/myapp/app/cache/dev/classes.php"캐시 파일 쓰기 실패

---

대부분의 경우 디렉토리 및 / 또는 하위 디렉토리 에 쓸 수 없음을 의미합니다. 많은 사람들이 하위 디렉토리를 잊어 버립니다.

심포니 2

chmod -R 777 app/cache app/logs

Symfony 3 디렉토리 구조

chmod -R 777 var/cache var/logs

추가 자료

Symfony의 권한 솔루션 (이전에 언급 됨).

KPN University의 권한 솔루션 -설치시 스크린 캐스트가 추가로 포함됩니다.

참고 : Symfony 3 디렉토리 구조를 사용하는 경우 app/cache및 app/logs을 var/cache및로 대체하십시오 var/logs.

---

폴더가 이미 쓰기 가능하므로 문제가되지 않습니다.

/www/projet_etienne/app/cache/거기에있는 폴더 (dev, dev_new, dev_old)로 이동하여 수동으로 제거 할 수도 있습니다 .

문제가 해결되지 않는 경우 해당 폴더의 복사본을 어딘가에 저장해 두십시오.

I know this is not the way it should be done but it worked for me a couple of times now.

---

You probably aborted a clearcache halfway and now you already have an app/cache/dev_old.

Try this (in the root of your project, assuming you're on a Unixy environment like OS X or Linux):

rm -rf app/cache/dev*

---

Maybe you forgot to change the permissions of app/cache app/log

I'm using Ubuntu so

sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs
sudo setfacl -dR -m u::rwX app/cache app/logs

Hope it helps..

---

i executed:

ps aux | grep apache

and got something like that:

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

so my user with no access turned out to be www-data thus i executed commands:

sudo chown -R www-data app/cache
sudo chown -R www-data app/logs

and it solved access errors.

Never-ever use unsecure 777 for solving specific access probles:

sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs

---

I move the whole directory from my Windows installation to a unix production server and I got the same error. To fix it, I just ran these two lines in unix and everything started to run fine

rm -rf app/cache/*
rm -rf app/logs/*

---

if symfony version less than 2.8

sudo chmod -R 777 app/cache/*

if symfony version great than or equal 3.0

sudo chmod -R 777 var/cache/*

---

Just use this acl cmd, next time the files inside var are created it will have the r/w/x permission for www-data user.

cd var 
rm -rf *
cd ..
setfacl -d -m u:www-data:rwx var

Cmd explanation:

setfacl -> Set acl command    
-d -> default behavior    
-m -> modify 
u:www-data: -> for user 
rwx -> adding permissions  
var -> on the folder

참고URL : https://stackoverflow.com/questions/13211829/symfony2-failed-to-write-cache-directory