Configurar el directorio temporal

Recientemente he movido un sitio de un localhost a un VPS. He logrado que los archivos públicos y privados se puedan escribir; Sin embargo, no estoy seguro de dónde encontrar la carpeta temporal y cómo cambiar los permisos. Sigo recibiendo este mensaje:

El archivo temporal especificado: // file3Hl91E no se pudo copiar, porque el directorio de destino no está configurado correctamente. Esto puede deberse a un problema con los permisos de archivo o directorio. Hay más información disponible en el registro del sistema.

Estoy usando Virtualmin, Drupal 7 y un servidor Debian. Mi directorio temporal actual es /tmp.

Verifique Administrador -> Configuración -> Medios -> Sistema de archivos para personalizar su ruta tmp. Asegúrese de utilizar rutas relativas y tener los privilegios correctos para el usuario de Apache.

Personalmente, me gusta la carga del archivo de este artículo . Él tiene buenas observaciones. Funcionó para mi.

Recientemente, descargué mi sitio a mi computadora Mac. Sucede que en mi Mac estaba usando mod_userdirApache y olvidé que /etc/apache2/users/nameofuser.confnecesito configurarlo AllowOverride All, de lo contrario tendré el siguiente mensaje:

El archivo temporal especificado no se pudo copiar porque el directorio de destino no está configurado correctamente.

En tu settings.php

$conf['file_temporary_path'] = '/tmp';

Esto funcionará en sistemas Unix el 99% del tiempo.

Por lo general, el directorio / tmp existe en sistemas UNIX con permisos abiertos, y existe específicamente para archivos temporales y, a menudo, está configurado para mejorar el rendimiento.

Puede verificar los permisos ejecutándose ls -al /tmpen la línea de comando.

Si está interesado en leer más sobre esto, consulte https://en.wikipedia.org/wiki/Temporary_folder

Es importante comprender que puede existir un problema de permisos en AMBOS el directorio temporal especificado (que se define en admin / config / media / file-system) Y en la carpeta donde se va a copiar ese archivo temporal. He visto este error varias veces y generalmente no es un problema con la carpeta temporal, sino la carpeta final donde se copia ese archivo después de vivir en la carpeta temporal.

También asegúrese de que la ruta del sistema de archivos públicos esté configurada correctamente.

Tuve este problema exacto y me aseguré de usar la ruta relativa (sitios / predeterminado / archivos / tmp) para la ubicación de mi carpeta tmp como se sugirió y también cambié los permisos en la carpeta tmp para asegurarme de que Apache pudiera escribirla, pero mi problema aún existía . así que decidí revisar los mensajes de registro (Informes >> Mensajes de registro recientes) para ver si podía comprender mejor cuál era el problema. Al hacer esto, recibí un mensaje más específico:

Los permisos de archivo no se pudieron establecer en public: // js.

Esto me llevó a verificar los permisos en la carpeta js en sites / default / files y, como resultado, apache no pudo escribir en él, así que al cambiar los permisos a 775 en esa carpeta me deshice de mi mensaje de error. Por lo tanto, sugeriría que verifique los permisos para todas las subcarpetas en sitios / archivos predeterminados / y no solo la carpeta tmp si aún no ha resuelto su problema. Solo pensé en compartir esta información.

puede encontrar la configuración del sistema de archivos en admin/config/media/file-system cambiarlo a / tmp

También puede consultar admin / informes / estado para cualquier problema de configuración

sobre el permiso / tmp puede darle 755 y lo encontrará en / public_html

El mensaje de error puede ser engañoso

Si dice que el problema tiene que ver con el directorio de destino, el apache probablemente no tiene los permisos para escribir en la subcarpeta de sitios / predeterminados / archivos en los que Drupal quiere colocar el archivo.

Una buena solución es hacer que el usuario de apache sea el propietario de todos los archivos y directorios en sites / default / files

cd /path/to/sites/default
sudo chown -R _www:_www files

O algo similar debería volver a resolver los problemas del directorio de destino. Verifique que el propietario tenga permisos de escritura y ejecución en todos los subdirectorios.

El directorio de archivos: Solución de problemas de servidores web basados ​​en Apache

Si los archivos de directorio no son "propiedad" del servidor web, hay dos formas de proceder. Estas instrucciones asumen que tiene acceso de shell al servidor web. Si no tiene acceso de shell, comuníquese con su proveedor de alojamiento para obtener asistencia adicional.

Idealmente, podrá cambiar el "propietario" de los archivos de directorio para que coincida con el nombre del servidor web. En un servidor basado en Unix o Linux, puede verificar "quién" está ejecutando el servidor web emitiendo los siguientes comandos:

$ ps aux  |grep apache # for Apache 2.x
$ ps aux  |grep httpd # for Apache 1.x

Dependiendo de su servidor web, uno de estos comandos devolverá una serie de líneas como esta:

www-data 13612  0.1  0.9  50640 20340 ? S 12:29   0:08 /usr/sbin/apache2 -k start

La primera columna en el texto devuelto es el "usuario" con el que opera su servidor web. En este caso, el usuario es www-data. Para que el servidor web pueda escribir su directorio de archivos, debe reasignar su propiedad utilizando el siguiente comando:

$ chown -R www-data sites/default/files
$ chmod -R 0700 sites/default/files

Si no tiene permisos suficientes en su servidor para cambiar la propiedad de la carpeta, la siguiente mejor opción es proporcionar acceso de escritura grupal a la carpeta con el siguiente comando:

$ chmod -R 0770 sites/default/files

También debe poder ajustar los permisos del directorio utilizando un programa FTP como se describe anteriormente.

Una vez que haya completado estos pasos, confirme que se han asignado los permisos apropiados navegando a Administrar -> Informes -> Informe de estado. Desplácese a la sección etiquetada "Sistema de archivos" y confirme que su configuración ahora es correcta.

Fuente: el directorio de archivos

Otra fuente de error es que no puede escribir en la carpeta de archivos. En mi caso lo resolví usando:

$chmod 777 sites/default/files/pictures/

En algunas situaciones, esto se puede solucionar fácilmente eliminando las carpetas 'ctools' y 'js' dentro de los archivos / predeterminados. El sistema recrea estas carpetas si es necesario. A veces, al realizar una nueva instalación de un sitio existente, estas carpetas existentes ya causan problemas. Además, si su CSS no funciona después de realizar una nueva instalación de un sitio existente, esto también se puede solucionar eliminando estos archivos y dejando que Drupal los vuelva a crear.

Mi configuración antigua y problemática

chmod 664 -R /var/drupal-bc/sites/default/files
chmod 664 -R /var/drupal-bc/sites/default/private

drw-rw-r-- 2 www-data www-data  4096 Jul 31 12:35 files
drw-rw-r-- 3 www-data www-data  4096 Jul  5 15:08 private

Mi nueva y buena configuración de trabajo

chmod 774 -R /var/drupal-bc/sites/default/files
chmod 774 -R /var/drupal-bc/sites/default/private

drwxrwxr-- 2 www-data www-data  4096 Jul 31 12:35 files
drwxrwxr-- 3 www-data www-data  4096 Jul  5 15:08 private

Los permisos correctos para la carpeta temporal dependen de la configuración de su servidor web.

Si ejecuta Drupal con PHP como módulo de servidor web, por ejemplo Apache, cuando el usuario que se define en el archivo de configuración del servidor web principal utilizando la directiva de usuario debería tener acceso de escritura.

% grep -i "usuario" /etc/httpd/conf/httpd.conf

Apache de usuario

Tuve este mismo problema después de pasar de un servidor a otro.

Intenté todo lo sugerido aquí, configurando carpetas en 755 y así sucesivamente.

Mi carpeta temporal se configuró en "" tmp7zXhVVCO "y en realidad copió muy bien los archivos de instalación, después de cada reintento vi que el archivo temporal se copiaba allí, pero la instalación seguía fallando.

Sin embargo, el problema es el propietario, no los derechos, por lo que 777 elimina este error, pero todos sabemos que esta no es una forma de ir a los sitios de producción.

Lo que debe hacer es cambiar su carpeta temporal a cualquier otra cosa, como "temp" o lo que le convenga, siempre que no exista , drupal creará esta nueva carpeta con derechos de apache , no derechos de usuario , y su problema Será resuelto.

Realmente no me gustan las respuestas existentes, así que solo voy a comenzar una que probablemente actualizaré con el tiempo. Principalmente con comandos de shell.

Por ahora, ejecute esto desde sites/example.com:

MYSITE=example.com
FILES=sites/$MYSITE/files  
# CSS and JS might also cause trouble and advagg has its own dirs
TMPDIRS=$FILES/tmp $FILES/js $FILES/css $FILES/advagg_*
drush vset file_temporary_path $FILES/tmp # seems better than using /tmp
drush vset file_directory_temp $FILES/tmp
cd $(drush drupal-directory)   
chown www-data -R $TMPDIRS
chmod 755 -R $TMPDIRS

Desde Configuración -> Medios -> Sistema de archivos, eliminé el / temp-catalog. Después de eso no tuve ningún problema.

Tuve el mismo problema en una migración. Tengo chmod 777 todos los sitios / archivos predeterminados / pero el error aún ocurre. Cambié el permiso 775 en sitios / predeterminado / archivos y el mensaje desapareció. No era un problema de ruta privada, el mío es / var / tmp pero el permiso 775.

Si se encuentra con este problema usando Pantheon y continúa obteniendo el error después de configurar la (s) ruta (s) del directorio de los archivos (temp), es posible que también deba cambiar el modo de Conexión en su tablero de instancia de desarrollo de Git a SFTP.

Su sitio de Drupal puede estar intentando guardar archivos en un directorio administrado por Git (por ejemplo, si está cambiando la configuración de diseño y similares en un tema de Temas adaptativos). Para hacerlo, cambie a SFTP. Una vez que los archivos se han guardado, puede volver a Git y el panel le pedirá que confirme los cambios que se han realizado en el servidor.

Yo tuve el mismo problema.

Estaba usando IIS en Windows. Finalmente, el problema era para los permisos en los sitios de carpeta / default / files y, obviamente, en sites / default / files / tmp.

Finalmente di nuevamente "Permisos completos" a las carpetas, y funcionó.

Saludos