Qué importa primero: WordPress intentó leer, crear, renombrar o incluir una ruta y el sistema operativo se negó. La ruta exacta y la operación importan más que una recomendación genérica 755/644.
Qué indica realmente este síntoma
Esto puede seguir migraciones, implementaciones de ejecución raíz, cambios en el volumen del contenedor o endurecimiento de la seguridad. Recursive chmod puede enmascarar errores de propiedad y exponer el código de escritura.
Recopila pruebas antes de cambiar nada
- Registrar la ruta exacta, la función y el funcionamiento de la advertencia o error fatal.
- Identifica el usuario PHP-FPM efectivo y el propietario del archivo, grupo y ACL.
- Comprueba si el sistema de archivos o el contenedor de montaje es de solo lectura.
- Compara un archivo de trabajo vecino o directorio creado por WordPress.
Causas más habituales
- Propietario equivocado: Los archivos fueron copiados o extraídos por root u otro usuario de implementación.
- Falta el acceso del grupo: El usuario de PHP no está en el grupo esperado por el modelo de implementación.
- Montaje de solo lectura: El contenedor o sistema de archivos de red previene intencionalmente las escrituras.
- Política de seguridad: Las reglas ACL, SELinux, AppArmor o servidoring anulan los bits del modo Unix.
Secuencia segura de diagnóstico y reparación
- Restaurar el modelo de propiedad documentado en lugar de ampliar cada permiso.
- Haga que solo se puedan escribir los directorios de tiempo de ejecución requeridos; Mantén plugin, tema y código central solo de lectura cuando sea posible.
- Aplicar la estrategia ACL o de grupo consistentemente para que el siguiente despliegue no revierta la solución.
- Volver a ejecutar la escritura exacta o incluir la operación e inspeccionar el propietario resultante.
Cómo distinguir entre las causas probables
No trates Propietario equivocado y Falta el acceso del grupo como causas equivalentes. Los archivos fueron copiados o extraídos por root u otro usuario de implementación. En cambio, el usuario de PHP no está en el grupo esperado por el modelo de implementación. Para distinguirlas, usa estas dos comprobaciones: Registrar la ruta exacta, la función y el funcionamiento de la advertencia o error fatal; y identifica el usuario PHP-FPM efectivo y el propietario del archivo, grupo y ACL. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Restaurar el modelo de propiedad documentado en lugar de ampliar cada permiso— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
Nunca aplique chmod -R 777 a WordPress. Crea una superficie de código de escritura y a menudo deja sin resolver el desajuste real del propietario.
Cómo verificar la reparación
- La operación de archivo original tiene éxito bajo el usuario PHP previsto.
- Los nuevos archivos reciben el propietario y el grupo correctos automáticamente.
- Los directorios de código no son más escribibles de lo que requiere el despliegue.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.