Arreglar “No se pudo escribir en disco” WordPress

Contexto del problema en WordPress

Este error encaja sobre todo en incidencias de sistema de archivos, actualizaciones y hosting. WordPress necesita escribir archivos en varias situaciones habituales: subir medios, descomprimir una actualización, crear miniaturas, guardar caché, instalar extensiones o exportar contenidos. Cuando no puede hacerlo, el fallo suele mostrarse con mensajes poco precisos y el usuario interpreta que el problema está en el editor o en la biblioteca multimedia, cuando en realidad la causa puede estar en permisos del servidor, espacio disponible, carpetas temporales de PHP o límites de cuenta.

En la práctica, el impacto no se limita al panel de administración. Si no se pueden escribir archivos, también pueden fallar tareas programadas, regeneración de imágenes, copias automáticas, registros de plugins, optimizaciones y algunas funciones de correo o comercio electrónico que generan adjuntos o documentos. En un entorno general o en España, el patrón varía según la arquitectura del proveedor, si usa contenedores, cachés a nivel servidor, jaulas de usuario, reglas de seguridad o almacenamiento compartido.

• Puede aparecer al subir una imagen, un PDF o cualquier archivo a la biblioteca.
• También es frecuente al actualizar plugins, temas o el núcleo de WordPress.
• Un mismo mensaje puede deberse a falta de espacio, permisos erróneos o carpeta temporal inaccesible.
• Si el sitio sigue visible pero el panel falla, no conviene asumir que el problema es menor.
• Cuanto antes se conserve evidencia técnica, más fácil será acotar la causa real.

Diagnóstico inicial y señales útiles

El primer paso es identificar exactamente cuándo aparece el error y si afecta solo a una acción concreta o a varias. Conviene anotar el texto completo del mensaje, la URL del área afectada, el tipo de archivo que se intentaba subir y la hora aproximada. Si el hosting envía avisos de cuota, inode, uso de CPU o errores de PHP, esa información tiene mucho valor. También ayudan las alertas de Search Console si coinciden con caídas o problemas de rastreo, aunque este error sea principalmente interno.

Las comprobaciones iniciales deben ser prudentes para no empeorar el problema. No es recomendable borrar carpetas, cambiar permisos de forma masiva a 777, reinstalar varios plugins ni restaurar copias sin revisar primero logs y espacio disponible. Mejor empezar con pruebas de lectura segura, verificar si el fallo se reproduce en staging y revisar el estado de salud del sitio, el administrador de archivos del hosting y los registros del servidor o de PHP si se dispone de ellos.

• Mensajes verificables: “No se pudo escribir en disco”, errores de subida, fallos al actualizar o avisos de carpeta temporal.
• Señales técnicas: caída de la subida de medios, miniaturas que no se generan, actualizaciones incompletas, picos de CPU o alertas del proveedor.
• Cambios recientes: actualización de WordPress o plugins, cambio de PHP, nueva regla de seguridad, migración o restauración parcial.
• Comprobaciones prudentes: revisar cuota de disco e inodes, confirmar permisos de wp-content y uploads, y consultar logs antes de modificar nada.
• Pruebas seguras: intentar subir un archivo pequeño, comprobar si falla solo un rol de usuario y contrastar el comportamiento en un entorno de staging.

Causas habituales y cómo confirmarlas

Las causas más comunes son cuatro: falta de espacio real o cuota agotada, permisos o propiedad incorrectos en archivos y carpetas, carpeta temporal de PHP inexistente o no accesible, y restricciones del proveedor o del sistema de seguridad del servidor. Menos a menudo intervienen rutas rotas tras una migración, discos montados en solo lectura, límites de inodes, plugins que interceptan subidas o procesos bloqueados por seguridad del hosting.

Confirmar la causa exige mirar evidencia concreta. Si la cuota está al límite, el error suele repetirse en varias operaciones y aparecen avisos del hosting. Si el problema es de permisos, afecta a carpetas concretas como wp-content/uploads. Si falla la carpeta temporal, los logs de PHP pueden mostrar referencias a upload_tmp_dir o a errores de escritura. Si el origen es una política del proveedor, el patrón puede aparecer tras endurecer reglas de seguridad, cambiar de plan o mover la web entre servidores.

• Espacio insuficiente: revise cuota, uso por correo, backups locales, cachés y número de inodes consumidos.
• Permisos o propiedad: compruebe si las carpetas permiten escritura al usuario correcto del servidor, sin abrir permisos inseguros.
• Carpeta temporal PHP: verifique si existe, si es escribible y si la configuración del servidor apunta a una ruta válida.
• Restricciones del proveedor: consulte si hay módulos de seguridad, contenedores o reglas anti abuso que bloqueen escritura.
• Rutas dañadas tras migración: confirme que uploads existe, que la estructura por año y mes es coherente y que no hay enlaces rotos.

Seguridad, malware y spam

Aunque “No se pudo escribir en disco” no sea un mensaje exclusivamente de seguridad, conviene no descartar esta vía. Un plugin vulnerable, credenciales filtradas o una inyección en el sitio pueden llenar espacio con archivos basura, generar spam saliente, crear copias ocultas o alterar permisos para persistir. También puede pasar lo contrario: una medida de hardening mal aplicada bloquea escritura en rutas que WordPress sí necesita usar para operar con normalidad.

La respuesta razonable no es alarmarse, sino revisar síntomas complementarios. Si además hay usuarios administradores no reconocidos, archivos recientes en rutas extrañas, picos de correo, redirecciones, cambios en .htaccess o consumo anómalo, conviene conservar copia, rotar contraseñas y revisar integridad antes de tocar permisos de forma indiscriminada. En caso de duda, el orden importa: copia, evidencia, contención y luego limpieza o corrección.

• Síntomas complementarios: nuevos archivos en uploads, cuentas no autorizadas, envíos de spam o cambios de permisos sin explicación.
• Vectores habituales: plugins o temas vulnerables, contraseñas reutilizadas, accesos por FTP inseguros o inyecciones en formularios.
• Medidas razonables: copia completa, rotación de contraseñas, revisión de usuarios, desactivación selectiva y hardening básico.
• No conviene aplicar permisos 777 ni borrar archivos sospechosos sin registrar antes rutas, fechas y cambios observados.
• Si hay sospecha de compromiso, una auditoría de plugins y logs ayuda a separar causa de consecuencia.

Rendimiento y estabilidad

La escritura en disco también se relaciona con rendimiento y estabilidad. Cuando el servidor opera con poco margen de espacio, memoria o procesos, operaciones sencillas como generar miniaturas o descomprimir una actualización pueden fallar. Los sistemas de caché, optimización de imágenes, copias locales y registros excesivos consumen recursos y espacio de forma silenciosa. El resultado puede ser un error intermitente que solo aparece bajo carga o en franjas concretas del día.

Conviene evaluar si el problema es puntual o estructural. Si el sitio crece y el entorno no se revisa, la misma biblioteca multimedia, el sistema de caché o los logs pueden acabar ocupando más de lo previsto. En un ámbito general, y también en España, muchos proveedores aplican límites por cuenta compartida, procesos simultáneos, inodes o I/O, de modo que el fallo puede emerger sin que la web esté aparentemente caída.

• La generación de miniaturas y conversiones de imagen puede fallar aunque la subida inicial parezca correcta.
• Las cachés de servidor o de plugin pueden ocupar espacio y bloquear escrituras posteriores.
• Logs muy grandes, backups almacenados en la propia cuenta y sesiones antiguas degradan la estabilidad.
• Un error intermitente suele apuntar a límites de recursos o a saturación temporal, no solo a permisos.
• La monitorización posterior permite comprobar si la incidencia era puntual o recurrente.

Plugins, temas y actualizaciones

Los plugins y temas intervienen de forma directa en este tipo de incidencias porque añaden procesos que escriben archivos, crean cachés, generan imágenes, exportan datos o modifican permisos. Tras una actualización, un complemento puede intentar usar una carpeta no existente, exigir más espacio temporal o entrar en conflicto con la versión de PHP o con medidas de seguridad del servidor. Por eso, aunque el mensaje aparezca en WordPress, el disparador real puede ser una extensión concreta.

La práctica recomendada es trabajar con staging cuando sea posible, mantener control de cambios y documentar compatibilidades mínimas. Si el error comenzó tras actualizar, conviene revisar qué versión cambió, qué rutas escribe ese componente y si la incidencia desaparece al desactivarlo de forma controlada en un entorno de prueba. Evite encadenar actualizaciones o cambios de tema mientras el diagnóstico sigue abierto, porque se pierde trazabilidad.

• Use staging para reproducir la subida o la actualización sin comprometer la web en producción.
• Revise changelog, requisitos de versión PHP y notas de compatibilidad del plugin o tema implicado.
• Desactive de forma selectiva, no masiva, y documente cada cambio para saber qué altera el comportamiento.
• Antes de actualizar, haga copia y confirme espacio suficiente para descompresión y archivos temporales.
• Si un conflicto aparece tras actualizar, no fuerce nuevas instalaciones sin revisar primero logs y permisos.

Hosting, dominio y correo en España

En este tipo de error, el hosting suele ser una pieza decisiva. Hay que revisar espacio total, inodes, versión de PHP, configuración de upload_tmp_dir, propiedad de archivos, límites de memoria, tamaño máximo de subida y existencia de cachés de servidor. También conviene comprobar si el proveedor aplica aislamiento por usuario, políticas WAF, discos temporales separados o reglas específicas de escritura. En España, estos parámetros varían mucho entre planes compartidos, VPS y entornos gestionados.

Aunque el problema no esté en el dominio o el correo, ambos pueden influir en el consumo de la cuenta. Los buzones locales, colas de correo transaccional, backups automáticos o logs de errores almacenados en el mismo plan pueden agotar recursos. A su vez, una migración DNS o un cambio de SSL no suele causar por sí mismo el error de escritura, pero sí puede coincidir con cambios de servidor, rutas, permisos o cachés que lo desencadenan.

• Revise DNS y SSL solo como parte del contexto de migración, no como causa principal del mensaje.
• Compruebe versión PHP, carpeta temporal, límites de upload, memoria e inodes en el panel del proveedor.
• Verifique si las cachés a nivel servidor o la compresión de archivos ocupan espacio o bloquean escritura.
• Si hay correo transaccional o buzones en la misma cuenta, revise consumo, colas y almacenamiento local.
• Solicite al proveedor logs y confirmación de la ruta temporal cuando el acceso técnico sea limitado.

Pruebas, accesos y documentación técnica

Para resolver este error con criterio, conviene trabajar con evidencias y accesos mínimos suficientes. No hace falta abrir todos los sistemas a la vez, pero sí reunir la información adecuada: acceso de administrador WordPress, panel del hosting, gestor de archivos o SFTP, y posibilidad de consultar logs. Si no se puede intervenir directamente, al menos debe recopilarse material que permita reconstruir la secuencia del fallo y decidir si la corrección corresponde a WordPress, al servidor o al proveedor.

La documentación previa ahorra tiempo y evita repetir pruebas. En especial, ayuda mucho saber desde cuándo falla, qué cambio se hizo antes, si existe staging, qué copias están disponibles y qué carpetas exactas muestran el error. Cuando se actúa con varios intervinientes, dejar constancia de cada paso impide contradicciones y facilita volver atrás si una prueba no sale como se esperaba.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, changelog interno y fecha del primer fallo.
• Evidencias técnicas: logs de PHP y servidor, capturas del mensaje, URLs afectadas, copia de seguridad y export de base de datos.
• Prueba útil: subida de un archivo pequeño y de otro distinto para confirmar si el fallo es general o depende del tipo de archivo.
• Prueba útil: revisión de wp-content/uploads y de la carpeta temporal para verificar existencia, permisos y última fecha de escritura.
• Accesos mínimos recomendables: WordPress admin, panel de hosting, SFTP o gestor de archivos y acceso a registros.

Plan de acción ordenado

La forma más segura de abordar “No se pudo escribir en disco” es seguir un orden estable. Primero se contiene el riesgo y se evita tocar más elementos de los necesarios. Después se realiza o verifica una copia útil. A continuación se diagnostica con datos, se aplica la corrección mínima viable y se valida el resultado con pruebas concretas. Solo después conviene limpiar restos, optimizar y dejar monitorización para detectar recaídas.

Este enfoque reduce tiempos de caída y evita errores secundarios. Cambiar permisos de forma agresiva, borrar cachés sin saber qué ocupan o reinstalar componentes al azar puede ocultar la causa y generar más trabajo. En un servicio profesional, lo habitual es documentar cada paso, confirmar qué se corrige y revisar el impacto antes de cerrar la incidencia.

• Contención: detenga cambios no esenciales y registre el error exacto, la hora y la operación que lo produce.
• Copia: confirme que existe backup reciente de archivos y base de datos antes de aplicar correcciones relevantes.
• Diagnóstico: revise espacio, inodes, permisos, carpeta temporal de PHP, logs y cambios recientes.
• Corrección: ajuste la causa específica, como liberar espacio, reparar permisos o corregir la ruta temporal.
• Verificación y seguimiento: pruebe subida, actualización y generación de miniaturas, y mantenga monitorización posterior.

Si ya se ha tocado algo o hay urgencia

No siempre se empieza desde cero. A veces ya se ha instalado un plugin de seguridad, restaurado una copia parcial, cambiado de hosting, editado functions.php, borrado un plugin crítico o intentado limpiar malware sin copia previa. En esos escenarios, la prioridad pasa por reconstruir qué se hizo, en qué orden y con qué efecto observable. Sin esa cronología, el error de escritura puede mezclarse con otros fallos introducidos durante la intervención.

La cautela principal es no perder evidencia técnica. No conviene sobrescribir logs, repetir restauraciones al azar ni borrar archivos sospechosos sin registro. Si ya hubo una restauración parcial, debe comprobarse la coherencia entre base de datos y archivos. Si se tocó functions.php o se eliminó un plugin esencial, es importante verificar que el problema actual siga siendo de escritura y no una consecuencia distinta. En una urgencia real, lo sensato es estabilizar primero y corregir después con trazabilidad.

• Si se instaló un plugin de seguridad, revise qué bloqueos, permisos o cuarentenas activó y desde cuándo.
• Si se restauró una copia parcial, confirme coherencia entre archivos, base de datos y rutas de uploads.
• Si se cambió de hosting, compare versión PHP, propiedad de archivos, límites de cuenta y carpeta temporal.
• Si se tocó functions.php o se borró un plugin crítico, recupere el cambio y valide si el error original sigue presente.
• Si se intentó limpiar malware sin copia, conserve evidencia restante y evite nuevas acciones destructivas sin plan.

Preguntas frecuentes

Estas dudas son habituales cuando WordPress muestra “No se pudo escribir en disco”. La respuesta correcta depende del entorno, pero hay pautas que ayudan a decidir sin improvisar.

P: ¿Este error significa siempre que el hosting se ha quedado sin espacio?

R: No. La falta de espacio es una causa frecuente, pero también puede deberse a permisos incorrectos, inodes agotados, carpeta temporal de PHP inaccesible o restricciones del proveedor.

P: ¿Puedo arreglarlo cambiando todos los permisos a 777?

R: No es recomendable. Ese cambio puede abrir un riesgo de seguridad y no garantiza la solución. Lo correcto es ajustar permisos y propiedad solo en las rutas afectadas y según el usuario del servidor.

P: ¿Qué prueba rápida aporta más información sin empeorar la incidencia?

R: Intentar una subida pequeña, revisar el espacio e inodes en el panel del hosting y consultar logs de PHP o del servidor suele ofrecer pistas útiles sin introducir cambios destructivos.

P: ¿Puede aparecer después de actualizar un plugin aunque antes funcionara bien?

R: Sí. Una actualización puede cambiar la forma en que el plugin escribe archivos, exigir más espacio temporal o revelar una incompatibilidad con PHP, permisos o medidas de seguridad del servidor.

P: ¿Cuándo conviene pedir una revisión técnica profesional?

R: Cuando no hay acceso claro a logs, el error afecta a ventas o captación, ya se han hecho cambios sin resultado o existen dudas entre problema de WordPress, seguridad y hosting. En esos casos, empezar por diagnóstico y copia suele ahorrar tiempo.