WordPress no instala plugins por permisos solución
WordPress no instala plugins por permisos: detecta si falla chmod, propietario o escritura y aplica la solución segura según tu hosting.
Si WordPress no instala plugins por permisos, lo más habitual es que el problema esté en los permisos del sistema de archivos, en que el propietario de las carpetas no coincide con el usuario con el que corre el servidor o en que WordPress está usando un método de escritura que no encaja con tu entorno. La solución práctica pasa por identificar primero qué falla en wp-content, plugins, uploads o upgrade y corregirlo sin abrir riesgos de seguridad.
Antes de tocar permisos o propietario, conviene hacer una copia de seguridad de archivos y base de datos. No todos los hostings funcionan igual: según uses cPanel, Plesk, FTP/SFTP, PHP-FPM, Apache, Nginx o un entorno gestionado, el remedio puede variar.
Por qué WordPress no puede instalar plugins por permisos
Cuando instalas o actualizas un plugin, WordPress necesita descargar el paquete, escribirlo en disco, descomprimirlo y mover archivos dentro de wp-content/plugins. En algunos casos también usa wp-content/upgrade como directorio temporal. Si no puede escribir en esas rutas, verás el error.
Aquí hay una diferencia importante: permisos no es lo mismo que propietario. El chmod define qué se puede hacer sobre un archivo o carpeta; el propietario indica qué usuario del sistema tiene control directo sobre ese recurso. Puedes tener permisos aparentemente correctos y, aun así, fallar si PHP se ejecuta con otro usuario.
También influye el método de escritura. WordPress puede intentar escribir directamente o pedir credenciales FTP. Forzar FS_METHOD sin diagnosticar antes puede ocultar el problema real, pero no corregir el origen, como ocurre al arreglar WordPress después de una actualización fallida.
Qué errores suelen aparecer y qué significan
Los mensajes más comunes suelen apuntar a escritura o creación de directorios:
- No se ha podido crear el directorio.
- Installation failed: Could not create directory.
- No se pudo copiar el archivo.
- No se puede descomprimir el paquete en wp-content.
- Para realizar la acción solicitada, WordPress necesita acceder a tu servidor web.
Si WordPress pide credenciales FTP, no significa necesariamente que falten datos de acceso; muchas veces indica que no puede escribir directamente con el usuario del servidor. Si el error aparece al actualizar plugins, el foco suele estar en plugins o upgrade, no solo en el plugin afectado.
Cómo comprobar si el fallo está en permisos, propietario o método de escritura
Empieza por revisar estas rutas: wp-content, wp-content/plugins, wp-content/uploads y, si existe, wp-content/upgrade. En muchos servidores Linux, valores habituales y prudentes son 755 para directorios y 644 para archivos. Eso no garantiza por sí solo que funcione, pero sirve como referencia segura.
Qué revisar en la práctica
- Si el panel del hosting muestra permisos extraños o carpetas no escribibles.
- Si los archivos fueron subidos por otro usuario vía FTP, migración o restauración.
- Si WordPress pide FTP de repente tras un cambio de servidor o de versión PHP.
Si tienes acceso a herramientas del hosting, busca el propietario o el usuario de la suscripción. En entornos gestionados, esta información puede no estar visible y tendrás que consultarlo con soporte. La referencia oficial de WordPress sobre permisos puede ayudarte a validar criterios básicos: Changing File Permissions.
Cómo corregirlo desde cPanel, FTP o el panel del hosting
Si usas cPanel, Plesk o un gestor de archivos del proveedor, revisa primero permisos de wp-content y subcarpetas. Ajustar directorios a 755 y archivos a 644 suele ser una corrección razonable cuando hay valores incoherentes. Evita usar 777: abre demasiado la escritura y no es una solución aceptable en producción.
Por FTP/SFTP puedes corregir permisos, pero normalmente no el propietario real del sistema. Esto importa mucho: si el fallo es de owner, cambiar chmod puede no resolver nada. Cuando el hosting asigna cada web a un usuario distinto, el propietario debe ser coherente con cómo ejecuta PHP ese entorno.
Si el panel del hosting incluye reparación de permisos o reasignación de propiedad, úsalo solo si el proveedor lo documenta claramente. En hosting administrado, a menudo la solución más segura es abrir un ticket indicando el error exacto y las rutas afectadas, especialmente si aparece “No se pudo escribir en disco”.
Qué hacer si necesitas una solución más avanzada en wp-config o por SSH
Si tienes conocimientos técnicos y tu proveedor lo permite, puedes revisar si WordPress está utilizando un método de escritura no adecuado. En algunos casos, definir FS_METHOD en wp-config.php ayuda a evitar que pida FTP y permite escritura directa. Aun así, esto solo tiene sentido si el usuario con el que corre PHP ya puede escribir de forma segura en las carpetas necesarias.
Si el problema es de propietario, la corrección real suele requerir SSH o intervención del proveedor, porque hay que ajustar ownership según el usuario correcto del sitio o del servicio web. No des por hecho que tendrás acceso root ni comandos disponibles; en muchos hostings compartidos no es así.
Tocar wp-config.php sin una comprobación previa puede hacer que el síntoma cambie, pero el error de base siga ahí. Si no tienes claro si el bloqueo es por método de escritura o por owner, es mejor no improvisar sin acceso FTP.
Cómo evitar que vuelva a ocurrir
- Mantén una forma de acceso principal coherente: mejor SFTP o panel del hosting que mezclas desordenadas de métodos.
- Evita restauraciones o migraciones que cambien propietario sin revisarlo después.
- No apliques permisos masivos inseguros para “probar”.
- Comprueba tras cambios de hosting, PHP-FPM o configuración del proveedor si WordPress sigue escribiendo con normalidad.
En resumen, cuando aparece un error permisos WordPress, lo importante no es solo “dar permisos”, sino identificar si falla el chmod, la propiedad o el método de escritura. Esa distinción evita parches inseguros y ahorra tiempo.
Si ya has revisado wp-content, has validado permisos razonables y el problema persiste, el siguiente paso sensato es pedir una revisión técnica del entorno antes de tocar más configuraciones. Una intervención puntual y bien diagnosticada suele resolverlo sin comprometer seguridad ni operativa, igual que clonar WordPress a staging para pruebas seguras ayuda a evitar cambios de riesgo en producción.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.