No se pueden instalar nuevos plugins debido al error "No se pudo crear el directorio"

Question

No se pueden instalar nuevos plugins debido al error "No se pudo crear el directorio"

24 sept 2010, 22:19:12

Vistas: 38.5K

Votos: 7

Un miembro de la facultad está teniendo problemas con una instalación de WordPress para instrucción. Corregir problemas individuales de permisos ha sido un proceso de prueba y error, y se ha convertido en un dolor recurrente, así que preguntaré aquí. ¿Qué puedo hacer para que WordPress funcione correctamente? Los tipos de errores que reciben:

Instalando Plugin: Lightbox 2 2.9.2 Descargando paquete de instalación desde http://downloads.wordpress.org/plugin/lightbox-2.2.9.2.zip… Descomprimiendo el paquete… No se pudo crear el directorio. /home/CIM140/public_html/wordpress/wp-content/upgrade/lightbox-2.tmp

Cuando hago su como www-data (el usuario bajo el que corre Apache en Ubuntu), puedo crear ese directorio sin problemas. Mi instancia de prueba de WordPress instala este plugin correctamente, así que no entiendo por qué falla para ellos.

jldugger

173

plugins permisos actualizaciones

Todas las respuestas a la pregunta

Comentarios

Ya lo hice =(

jldugger

24 sept 2010 22:39:50

ejemplo: drwxrwsr-x 6 www-data www-data 4096 2010-09-22 23:15 wp-content

jldugger

24 sept 2010 22:40:53

Intenta cambiarlos a drwxr-xr-x 7 www-data www-data 4096 Sep 24 09:38 wp-content

Chris_O

24 sept 2010 23:01:13

También nunca he usado el atributo SGID en un directorio, es decir: chmod g+s No creo que sea necesario. Que alguien me corrija si estoy equivocado.

Chris_O

24 sept 2010 23:13:02

Ah, después de contactar al profesor, parece que está usando SSH por defecto mientras que mi instancia de prueba usa IO directo. Así que es su usuario el que no tiene permisos para crear el directorio.

jldugger

25 sept 2010 01:17:48

Mostrar los 1 comentarios restantes

Para entender por qué estás teniendo estos problemas, necesitas comprender los conceptos subyacentes de propiedad de archivos.

Básicamente, sabes que Apache se ejecuta como el usuario www-data. Es por eso que establecer que todo sea propiedad de ese usuario funciona, porque WordPress verifica que puede crear archivos como el usuario que posee sus propios archivos. Entonces, lo que estás haciendo es hacer que todo sea propiedad del usuario que posee los archivos.

Si tienes control total y absoluto de la máquina, esto está bien. Por otro lado, si es un servidor de alojamiento compartido, entonces has creado un agujero de seguridad.

Normalmente, los servidores web se ejecutan como algún usuario (como www-data) que luego ejecuta código de otros usuarios (como "otto", mi cuenta de usuario). En esta situación, el servidor web no tendría la capacidad de crear archivos como "otto" y, por lo tanto, no podría crear archivos correctamente como mi cuenta. Por lo tanto, esta verificación de WordPress sobre la creación de archivos con la propiedad correcta y, por lo tanto, la capacidad de instalar plugins o actualizar archivos fallaría, correctamente, porque tener mis archivos propiedad del usuario compartido del servidor web sería un riesgo de seguridad.

En tal caso, WordPress debería solicitarme correctamente credenciales FTP, o algo por el estilo. Estas serían una forma de solucionar el problema de la cuenta de usuario autenticándose como el usuario que debería escribir los archivos y luego escribiéndolos como ese usuario.

Ahora, estás intentando resolver este problema cambiando todos los archivos de WordPress para que sean propiedad de la misma cuenta que el servidor web utiliza para escribir los archivos. El enfoque más normal para esto es cambiar cómo el servidor web escribe los archivos, para permitir que el proceso PHP sea "propiedad" de la cuenta de usuario que está ejecutando los archivos.

La respuesta general a esto es "suphp". Esta versión de PHP establece que el usuario que ejecuta el proceso PHP sea el mismo que el propietario de los archivos PHP que está ejecutando. Esto es más seguro en configuraciones de alojamiento compartido, porque garantiza que un proceso PHP ejecutado por el servidor web compartido se ejecute como el propietario de los archivos PHP y, por lo tanto, no pueda leer las cuentas de otros usuarios y similares.

En Ubuntu, creo que esta es la forma general de hacerlo:

Instalar suphp:

$ sudo apt-get install libapache2-mod-suphp

Deshabilitar el antiguo mod_php

$ sudo a2dismod php5

Reiniciar Apache

$ sudo /etc/init.d/apache2 restart

Y listo. Ahora, haz que tus archivos PHP de WordPress sean propiedad del propietario normal de ellos. Sin trucos especiales, sin cambiar permisos o propiedad ni nada por el estilo. Dado que el proceso PHP se ejecutará como el propietario de esos archivos, podrá escribir en ellos como ese propietario. Los directorios deben tener permisos 755, los archivos deben tener 644 (nota: a suphp no le gusta cuando los archivos son editables por grupo, por lo que 755/644 es el conjunto de permisos correcto).

Otto

32.8K

17 abr 2016 12:31:35

Para mí (en Ubuntu) tuve que agregar umask 002 a /etc/apache2/envvars para que Wordpress subiera plugins/imágenes con permisos 775 en lugar de 755 (es decir, permitir que cualquiera además de Apache y root pueda modificar los archivos subidos)

willbradley

99

27 sept 2013 01:32:39

Necesitas dar permisos de escritura a los directorios relevantes. Idealmente, deberías hacerlo solo para el archivo o carpeta específica y luego revertir los permisos para no dejar tu sitio vulnerable.

Puedes solucionar esto usando los siguientes comandos desde la línea de comandos (asumiendo que estás en la carpeta raíz de WordPress):

# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade

La solución más segura es agregar apache al mismo grupo que el propietario de la instalación de WordPress y cambiar todos los permisos de grupo a escritura.

Varun

99

17 abr 2016 10:03:28

Comentarios

Si existe una solución más detallada, agréguela aquí, en lugar de enlazarla. 2. no, el servidor web no debería de ninguna manera tener la capacidad de escribir directamente en los directorios de código, a menos que disfrutes ser hackeado.

Mark Kaplun

17 abr 2016 10:14:30

@MarkKaplun pero entonces las actualizaciones de extensiones no funcionan, lo que la mayoría de usuarios de WP considera la forma "normal" de administrar un sitio. Una afirmación un poco demasiado fuerte. Que el servidor pueda escribir sobre wp-content es relativamente peor para la seguridad, pero por sí solo no es un gran problema.

Rarst

18 abr 2016 09:36:12

@MarkKaplun: Incluso la respuesta aceptada básicamente dice lo mismo - lo único es que es específica para Apache mientras que la mía es genérica.

Varun

23 jun 2016 07:31:14

Si tu respuesta es la misma, ¿cuál es el sentido de tenerla? 2. ¿Quién dijo que la respuesta aceptada es genial?

Mark Kaplun

23 jun 2016 08:54:52

@Rarst, también es menos conveniente cerrar con llave la puerta principal de la casa y cerrar las ventanas. Si las personas prefieren buscar archivos hackeados por todo su servidor en lugar de solo en el directorio de uploads, pueden hacer lo que sugiere la respuesta. Las actualizaciones de plugins/temas de Wordpress se hacen mejor a través de un servidor ftp si no te molesta usar una aplicación cliente sftp.

Mark Kaplun

23 jun 2016 09:03:00

A veces he tenido sitios donde corregir los permisos de directorios y archivos no era suficiente para solucionar este problema. Luego descubrí que uno o más directorios tenían el atributo de inmutabilidad activado. Esto se puede resolver fácilmente ejecutando chattr -R /var/www/sub.domain.tld como root.

Phil Gardner

1

28 nov 2019 17:08:49

Aquí una solución muy sencilla es: cambiar los permisos de la carpeta opt ejecutando el comando sudo chmod -R 777 /opt.

Kumar Saurabh

1

7 ene 2021 07:32:29

Comentarios

Por favor [edita] tu respuesta, y agrega una explicación: ¿por qué esto podría resolver el problema? ¿Por qué crees que es una buena solución permitir que todos lean, escriban y ejecuten archivos en estos directorios?

fuxia

8 ene 2021 02:04:01

Chris_O 20.6K · Accepted Answer · 2010-09-24T22:35:44Z

@pwnguin,

Tuve los mismos problemas al ejecutar mod_php con WordPress y finalmente lo resolví.

# chown www-data:www-data  /home/CIM140/public_html/wordpress/ -R

Mientras TÚ controles el servidor, esto no causará problemas de seguridad.

EDITADO:

También podrías necesitar cambiar tu umask a 022 para que los nuevos directorios creados por WordPress tengan permisos 755 y los archivos tengan permisos 644.

Otra opción es sobrescribir los permisos predeterminados en wp-config.php:

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

También puedes forzar el método del sistema de archivos para actualizaciones.

(Preferencia Principal) "Direct" fuerza el uso de solicitudes Directas de E/S de archivos desde PHP, esto puede abrir problemas de seguridad en hosts mal configurados, se elige automáticamente cuando es apropiado.
(Preferencia Secundaria) "ssh" fuerza el uso de la Extensión SSH de PHP.
(3ra Preferencia) "ftpext" fuerza el uso de la Extensión FTP de PHP para acceso FTP, y finalmente
(4ta Preferencia) "ftpsockets" utiliza la Clase Sockets de PHP para acceso FTP.

Estos pueden definirse en wp-config.php con: define('FS_METHOD', 'ftpext');

Puedes obtener todas las constantes definidas actualmente ejecutando el comando print_r(@get_defined_constants()); en php.