unable - symfony2: error al escribir el directorio de caché
symfony cache logs permissions (8)
Lo más probable es que signifique que el directorio y / o los subdirectorios no pueden escribirse. Muchos olvidan los subdirectorios.
Symfony 2
chmod -R 777 app/cache app/logs
Estructura del directorio de Symfony 3
chmod -R 777 var/cache var/logs
Recursos adicionales
Solución de permisos de Symfony (mencionada anteriormente).
La solución de permisos de KPN University - incluye adicionalmente un screen-cast en la instalación.
Nota: Si está utilizando la estructura de directorios de Symfony 3, sustituya la app/cache y la app/logs con var/cache y var/logs .
He tenido que usar el
app/console cache:clear command
para resolver un problema al generar una entidad.
Ahora no puedo cargar mi página de inicio en:
http://localhost/projet_etienne/web/app_dev.php
dice :
RuntimeException: no se pudo escribir el archivo de caché "/var/www/projet_etienne/app/cache/dev/classes.php".
¡No entiendo mucho sobre este negocio de caché!
En mi carpeta de app/cache , obtuve un dev , un dev_new , una carpeta dev_old . ¿Eso es normal?
el
app/console cache:clear
genera por cierto a:
[ErrorException] Advertencia: cambiar el nombre (/ var / www / projet_etienne / app / cache / dev, / var / www / projet_etien
ne / app / cache / dev_old): directorio no vacío en / var / www / projet_etienne / vendo
r / symfony / symfony / src / Symfony / Bundle / FrameworkBundle / Command / CacheClearComm
and.php línea 77
¡por favor ayuda!
Muevo todo el directorio de mi instalación de Windows a un servidor de producción de Unix y recibí el mismo error. Para solucionarlo, acabo de ejecutar estas dos líneas en Unix y todo comenzó a funcionar bien
rm -rf app / cache / * rm -rf app / logs / *
Para obtener una solución BUENA y definitiva, consulte la sección Setting up Permissions en la sección Installing and Configuring Symfony :
Configurando Permisos
Un problema común al instalar Symfony es que los directorios de la aplicación / caché y la aplicación / registros deben poder escribirse tanto en el servidor web como en el usuario de la línea de comandos. En un sistema UNIX, si el usuario de su servidor web es diferente de su usuario de línea de comandos, puede probar una de las siguientes soluciones.
- Use el mismo usuario para la CLI y el servidor web
En entornos de desarrollo, es una práctica común utilizar el mismo usuario de UNIX para la CLI y el servidor web porque evita cualquiera de estos problemas de permisos al configurar nuevos proyectos. Esto se puede hacer editando la configuración de su servidor web (por ejemplo, comúnmente httpd.conf o apache2.conf para Apache) y estableciendo que su usuario sea el mismo que su usuario CLI (por ejemplo, para Apache, actualice los valores de Usuario y Grupo).
- Usar ACL en un sistema que admite chmod + a
Muchos sistemas le permiten usar el comando chmod + a. Pruebe esto primero, y si obtiene un error, intente con el siguiente método. Utiliza un comando para tratar de determinar el usuario de su servidor web y configurarlo como 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
- Usar ACL en un sistema que no admite chmod + a
Algunos sistemas no son compatibles con chmod + a, pero admiten otra utilidad llamada setfacl. Es posible que deba habilitar el soporte de ACL en su partición e instalar setfacl antes de usarlo (como es el caso de Ubuntu). Utiliza un comando para tratar de determinar el usuario de su servidor web y configurarlo como 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/logsPara Symfony 3 sería:
$ 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 esto no funciona, intente agregar la opción -n.
- Sin usar ACL
Si ninguno de los métodos anteriores funciona para usted, cambie la umask para que los directorios de caché y de registro sean de escritura grupal o de escritura mundial (dependiendo de si el usuario del servidor web y el usuario de la línea de comandos están en el mismo grupo o no). Para lograr esto, coloque la siguiente línea al comienzo de los archivos de la aplicación / consola, web / app.php y web / app_dev.php:
umask(0002); // This will let the permissions be 0775 // or umask(0000); // This will let the permissions be 0777Tenga en cuenta que se recomienda utilizar ACL cuando tiene acceso a ellos en su servidor porque cambiar el umask no es seguro para subprocesos.
source: Error al escribir el archivo de caché "/var/www/myapp/app/cache/dev/classes.php" al borrar el caché
Probablemente abortó un clearcache a la mitad y ahora ya tiene una aplicación / cache / dev_old.
Pruebe esto (en la raíz de su proyecto, suponiendo que esté en un entorno Unixy como OS X o Linux):
rm -rf app/cache/dev*
Si la carpeta ya puede escribirse, ese no es el problema.
También puede navegar a /www/projet_etienne/app/cache/ y eliminar manualmente las carpetas allí (dev, dev_new, dev_old).
Asegúrese de guardar una copia de esa carpeta en algún lugar para volver a colocarla si esto no soluciona el problema
Sé que esta no es la forma en que debería hacerse, pero funcionó para mí un par de veces.
Tal vez se olvidó de cambiar los permisos de la aplicación / caché de la aplicación / registro
Estoy usando Ubuntu entonces
sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs
sudo setfacl -dR -m u::rwX app/cache app/logs
Espero eso ayude..
ejecuté:
ps aux | grep apache
y obtuve algo como eso:
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
entonces mi usuario sin acceso resultó ser www-data así que ejecuté comandos:
sudo chown -R www-data app/cache
sudo chown -R www-data app/logs
y resolvió los errores de acceso.
Nunca use inseguro 777 para resolver problemas específicos de acceso:
sudo chmod -R 777 app/cache
sudo chmod -R 777 app/logs
si la versión de Symfony es menor que 2.8
sudo chmod -R 777 app/cache/*
si la versión de Symfony es igual o mayor a 3.0
sudo chmod -R 777 var/cache/*