No se pueden cargar medios a través del cargador de WordPress

Esto tiene que ver con la carga de medios en WordPress.

Cada vez que WP crea una carpeta para nuevas cargas (organiza las cargas por año y mes: aaaa/mm), la crea con el usuario y grupo “apache:apache”, con acceso total a todos (777 o drwxrwxrwx).

Sin embargo, después de eso, WP no puede crear una carpeta dentro de esa carpeta (p. ej.: mkdir 2011 tiene éxito, pero mkdir 2011/01 falla). Además, las cargas no se pueden mover a estas carpetas recién creadas aunque los permisos sean 777 (rwxrwxrwx).

Una vez al mes, tengo que chown las carpetas recién creadas serán las mismas que usuario:grupo que el resto de los archivos. Una vez que hago eso, la carga funciona bien (lo que no tiene sentido para mí). La parte realmente frustrante es que este problema no existe en otras instalaciones de WP en otros dominios en el mismo servidor.

* No estaba seguro de si esto debería estar aquí o en serverfault.

Editar: el directorio contenedor /.../httpdocs/blog/wp-content/uploads tiene la propiedad correcta

drwxrwxrwx 5 myuser psaserv 4096 Jun  3 18:38 uploads

Este es un entorno Plesk/CentOS alojado por Media Temple (dv).

He escrito el siguiente script de prueba para simular el problema

<pre><?php 

$d = "d" . mt_rand(100, 500);

var_dump(
    get_current_user(),
    $d,
    mkdir($d),
    chmod($d, 0777),
    mkdir("$d/$d"),
    chmod("$d/$d", 0777),
    fileowner($d),
    getmyuid()
);

El script siempre crea el primer directorio. mkdir($d) exitosamente. En el dominio A, donde está el problema de WP, no puede crear el directorio anidado mkdir("$d/$d"). Sin embargo, en el dominio B, ambos directorios se crean correctamente.

Estoy ejecutando cada script en /var/www/vhosts/domainA/httpdocs/tmp/t.php y /var/www/vhosts/domainB/httpdocs/tmp/t.php respectivamente revisé los permisos en tmp, httpdocsy domain[AB] y son los mismos para cada camino. Lo único que difiere es el usuario.

Una solución es usar FastCgi. Esto hace que PHP se ejecute como el usuario propietario del sitio. Los nuevos archivos y carpetas serán del mismo usuario y grupo. Esto resolverá tu problema.

Hay una penalización de rendimiento para FastCgi, pero obtienes algo de seguridad adicional ya que restringe php. Si está alojando varios sitios web con varios usuarios, esta podría ser una buena idea.

Intente ir a su página de configuración miscelánea (o medios dependiendo de su versión) y asegúrese de que el directorio de carga siga siendo wp-content/uploads.

Si lo necesitas. establecer la url completa también.

Además, como solución final, deshabilite la opción de organizarlos en carpetas para que WordPress ni siquiera necesite crear carpetas.

Busque un bit setuid o setgid en un directorio por encima del directorio 2010. ls -l tendrá una s o S ​​en los permisos para el directorio. Asegúrese de que este directorio tenga la propiedad correcta.

Intenta crear un directorio recursivo con mkdir($d, true)

<pre><?php 

$d = "d" . mt_rand(100, 500);

var_dump(
         array(
               get_current_user(),
               $d,
               mkdir($d,true),
               chmod($d, 0777),
               mkdir("$d/$d", true),
               chmod("$d/$d", 0777),
               fileowner($d),
               getmyuid()
              )
        );

Tuve un problema similar con Joomla recientemente y resolví el problema agregando myuser al grupo apache y agregando apache al grupo psaserv.

Uno de nuestros sitios web en un Media Temple DV estaba teniendo este problema. Desactivar el modo seguro de PHP lo resolvió. Los directorios todavía se crearon como apache:apache, pero los archivos multimedia estaban permitidos allí.

Una cosa que se me ocurrió: WP le dirá que no puede copiar el archivo a /wp-content/upload incluso cuando todos los permisos son correctos… si

upload_max_filesize

en php.ini es demasiado pequeño (digamos 2M e intenta cargar un archivo de 3,5 MB)!

¡Espero que eso ayude a todos aquellos que tienen los permisos correctos pero aún no pueden cargar!