symfony2: échec de l'écriture du répertoire de cache
J'ai dû utiliser le
app/console cache:clear command
pour résoudre un problème lors de la génération d'une entité.
Je suis maintenant incapable de charger ma page d'accueil sur:
http://localhost/projet_etienne/web/app_dev.php
ça dit :
RuntimeException: échec de l'écriture du fichier cache "/var/www/projet_etienne/app/cache/dev/classes.php".
Je ne comprends pas grand chose à propos de cette affaire de cache!
Dans mon dossier app/cache, j'ai une dev, un dev_new, un dev_old. Est-ce normal?
la
app/console cache:clear
génère au passage a:
[ErreurException] Attention: renommer (/ var/www/projet_etienne/app/cache/dev,/var/www/projet_etien
ne/app/cache/dev_old): répertoire non vide dans/var/www/projet_etienne/vendo
r/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/CacheClearComm
and.php ligne 77
aidez s'il vous plaît!
Pour une solution BONNE et définitive, voir la section Setting up Permissions dans la section Installing and Configuring Symfony:
Configuration des autorisations
Un problème courant lors de l’installation de Symfony est que l’app/cache et Les répertoires app/logs doivent être accessibles en écriture à la fois par le serveur Web et par le fichier utilisateur en ligne de commande. Sur un système UNIX, si votre utilisateur de serveur Web est différent de votre utilisateur de ligne de commande, vous pouvez essayer l’un des fichiers solutions suivantes.
- Utiliser le même utilisateur pour la CLI et le serveur Web
Dans les environnements de développement, il est courant d’utiliser la même chose Utilisateur UNIX pour la CLI et le serveur Web, car cela évite le ces autorisations posent problème lors de la configuration de nouveaux projets. Cela peut être Pour ce faire, modifiez la configuration de votre serveur Web (par exemple, généralement httpd.conf ou Apache2.conf pour Apache) et définissez son utilisateur sur identique à votre utilisateur CLI (par exemple, pour Apache, mettez à jour les valeurs User et Group ).
- Utilisation de la liste de contrôle d'accès sur un système prenant en charge chmod + a
De nombreux systèmes vous permettent d'utiliser la commande chmod + a. Essayez ceci en premier, et si vous obtenez une erreur - essayez la méthode suivante. Ceci utilise une commande pour essayez de déterminer votre utilisateur de serveur Web et de 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
- Utilisation de la liste de contrôle d'accès sur un système ne prenant pas en charge chmod + a
Certains systèmes ne prennent pas en charge chmod + a, mais prennent en charge un autre utilitaire appelé setfacl. Vous devrez peut-être activer le support ACL sur votre partition et installez setfacl avant de l’utiliser (comme c’est le cas avec Ubuntu). Ce 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 -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/logsPour 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 -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/logsSi ce ne fonctionne pas, essayez d'ajouter l'option -n.
- Sans utiliser ACL
Si aucune des méthodes précédentes ne fonctionne pour vous, changez le umask pour que les répertoires de cache et de journal seront en écriture de groupe ou en écriture de monde (selon que l'utilisateur du serveur Web et l'utilisateur de la ligne de commande appartiennent au même groupe ou non). 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 0777Notez que l’utilisation de la liste de contrôle d’accès est recommandée lorsque vous y avez accès sur votre serveur car changer d'umask n'est pas thread-safe.
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 de répertoire Symfony 3
chmod -R 777 var/cache var/logs
Ressources supplémentaires
Solution d'autorisations de Symfony (mentionné précédemment).
La solution de droit d’autorisation de l’Université KPN - 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, le problème ne se pose pas.
Vous pouvez également simplement naviguer vers /www/projet_etienne/app/cache/ et supprimer manuellement les dossiers qu’il contient (dev, dev_new, dev_old).
Assurez-vous de sauvegarder une copie de ce dossier quelque part pour pouvoir la remettre si cela ne résout pas le problème
Je sais que ce n'est pas comme cela que cela devrait être fait, mais cela a fonctionné pour moi à quelques reprises maintenant.
Vous avez probablement annulé un clearcache à mi-chemin et 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 comme OS X ou Linux):
rm -rf app/cache/dev*
Peut-être avez-vous oublié de modifier les autorisations de app/cache app/log
J'utilise Ubuntu alors
Sudo chmod -R 777 app/cache
Sudo chmod -R 777 app/logs
Sudo setfacl -dR -m u::rwX app/cache app/logs
J'espère que ça aide..
Je déplace le répertoire entier de mon installation Windows vers un serveur de production Unix et j'ai la même erreur. Pour résoudre ce problème, je viens d'exécuter ces deux lignes sous Unix et tout a commencé à fonctionner correctement
rm -rf app/cache/*
rm -rf app/logs/*
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 accès s'est avéré être www-data donc j'ai exécuté les commandes
Sudo chown -R www-data app/cache
Sudo chown -R www-data app/logs
et cela a résolu les erreurs d'accès.
N'utilisez jamais le 777 non sécurisé pour résoudre des problèmes d'accès spécifiques:
Sudo chmod -R 777 app/cache
Sudo chmod -R 777 app/logs
si la version de symfony est inférieure à 2.8
Sudo chmod -R 777 app/cache/*if symfony version great than or equal 3.0
Sudo chmod -R 777 var/cache/*Utilisez simplement cette commande acl, la prochaine fois que les fichiers de var seront créés, ils disposeront de l’autorisation r/w/x pour l’utilisateur www-data.
cd var
rm -rf *
cd ..
setfacl -d -m u:www-data:rwx var
Cmd explication:
setfacl -> Set acl command
-d -> default behavior
-m -> modify
u:www-data: -> for user
rwx -> adding permissions
var -> on the folder