symfony2: impossible d’écrire le répertoire de cache

Pour une solution GOOD et définie, voir la section Setting up Permissions dans la section Installing and Configuring Symfony :

Configuration des permissions

Un problème commun lors de l’installation de Symfony est que les répertoires app / cache et app / logs doivent être accessibles en écriture à la fois par le serveur Web et par l’utilisateur de la ligne de commande. Sur un système UNIX, si l’utilisateur de votre serveur Web est différent de votre utilisateur de ligne de commande, vous pouvez essayer l’une des solutions suivantes.

1. Utilisez le même utilisateur pour la CLI et le serveur Web

Dans les environnements de développement, il est courant d’utiliser le même utilisateur UNIX pour l’interface de ligne de commande et le serveur Web, car cela évite tout problème d’autorisation lors de la configuration de nouveaux projets. Cela peut être fait en éditant votre configuration de serveur Web (par exemple, communément httpd.conf ou apache2.conf pour Apache) et en définissant son utilisateur comme votre utilisateur CLI (par exemple, pour Apache, mettez à jour les valeurs utilisateur et groupe).

2. Utiliser ACL sur un système qui supporte chmod + a

De nombreux systèmes vous permettent d’utiliser le chmod + une commande. Essayez ceci en premier, et si vous obtenez une erreur, essayez la méthode suivante. Cela utilise une commande pour essayer de déterminer votre utilisateur de serveur Web et le définir comme 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. Utiliser ACL sur un système qui ne supporte pas chmod + a

Certains systèmes ne supportent pas chmod + a, mais supportent un autre utilitaire appelé setfacl. Vous devrez peut-être activer le support ACL sur votre partition et installer setfacl avant de l’utiliser (comme c’est le cas avec Ubuntu). Cela utilise une commande pour essayer de déterminer votre utilisateur de serveur Web et le définir comme 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 -mu:"$HTTPDUSER":rwX -mu:`whoami`:rwX app/cache app/logs $ sudo setfacl -dR -mu:"$HTTPDUSER":rwX -mu:`whoami`:rwX app/cache app/logs 

Pour Symfony 3, ce serait:

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

Si cela ne fonctionne pas, essayez d’append l’option -n.

4. Sans utiliser ACL

Si aucune des méthodes précédentes ne fonctionne pour vous, modifiez le paramètre umask de sorte que les répertoires de cache et de journal soient accessibles en écriture par groupe ou accessibles en écriture pour le monde entier (selon que l’utilisateur du serveur Web appartient ou non au même groupe). Pour ce faire, placez la ligne suivante au début des fichiers app / console, web / app.php et web / app_dev.php:

 umask(0002); // This will let the permissions be 0775 // or umask(0000); // This will let the permissions be 0777 

Notez que l’utilisation de la liste de contrôle d’access est recommandée lorsque vous y avez access sur votre serveur, car la modification de umask n’est pas adaptée aux threads.

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

source: Impossible d’écrire le fichier cache “/var/www/myapp/app/cache/dev/classes.php” lors de la suppression du cache

Cela signifie très probablement que le répertoire et / ou les sous-répertoires ne sont pas accessibles en écriture. Beaucoup oublient les sous-répertoires.

Symfony 2

 chmod -R 777 app/cache app/logs 

Structure du répertoire Symfony 3

 chmod -R 777 var/cache var/logs 

Ressources additionnelles

Solution d’permissions par Symfony (mentionné précédemment).

Solution d’permissions par KPN University – comprend en outre une projection d’écran lors de l’installation.

Remarque: Si vous utilisez la structure de répertoires Symfony 3, remplacez app/cache et app/logs par var/cache et var/logs .

Si le dossier est déjà accessible en écriture, ce n’est pas le problème.

Vous pouvez aussi naviguer vers /www/projet_etienne/app/cache/ et supprimer manuellement les dossiers (dev, dev_new, dev_old).

Assurez-vous de SAUVEGARDER une copie de ce dossier quelque part pour la remettre si cela ne résout pas le problème.

Je sais que ce n’est pas ainsi que cela devrait être fait, mais cela a fonctionné pour moi deux fois maintenant.

Vous avez probablement annulé un clearcache à mi-chemin et maintenant vous avez déjà une application / cache / dev_old.

Essayez ceci (à la racine de votre projet, en supposant que vous êtes sur un environnement Unixy tel que OS X ou Linux):

rm -rf app/cache/dev*

Peut-être que vous avez oublié de modifier les permissions de l’application app / cache / log

J’utilise Ubuntu donc

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

J’espère que cela aide..

j’ai exécuté:

 ps aux | grep apache 

et a quelque chose comme ça:

 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 

donc mon utilisateur sans access s’est avéré être www-data donc j’ai exécuté des commandes:

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

et il a résolu les erreurs d’access.

N’utilisez jamais un 777 non sécurisé pour résoudre des problèmes d’access spécifiques:

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

Je déplace tout le répertoire de mon installation Windows vers un serveur de production Unix et j’ai la même erreur. Pour y remédier, je viens de lancer ces deux lignes dans unix et tout a bien commencé

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

si version de symfony moins de 2.8

 sudo chmod -R 777 app/cache/*