Permisos S3 fallan con Offload Media, solución
Si permisos S3 fallan con Offload Media, revisa IAM, bucket y región para resolver Access Denied y recuperar la subida de medios.
Cuando los permisos S3 fallan con Offload Media, el problema suele estar en una combinación de credenciales IAM, política del bucket, región, acceso a objetos o ajustes del propio plugin. No hay una causa única: el error puede aparecer al subir, copiar, servir o eliminar archivos, y cada operación puede requerir permisos distintos.
Si ves un error Access Denied en S3 o fallos al sincronizar la librería multimedia, conviene revisar primero qué acción concreta está fallando y después validar IAM, bucket, región y configuración de WP Offload Media antes de ampliar permisos en producción.
Qué suele provocar el error de permisos entre S3 y Offload Media
Los problemas con Offload Media suelen venir de varios puntos. El más habitual es que las credenciales IAM tengan permisos insuficientes para la operación real que intenta hacer WordPress: no es lo mismo subir un archivo que leerlo, copiarlo entre rutas o borrarlo después.
También conviene revisar si la política de bucket es demasiado restrictiva, si el bucket está en otra región distinta de la configurada en el plugin, o si el acceso a objetos está condicionado por Object Ownership, ACL desactivadas o bloqueo de acceso público. En algunos entornos, CloudFront o una CDN pueden hacer pensar que el fallo es de permisos cuando en realidad afecta al servido de URLs o a caché.
Otra causa frecuente es la herencia de objetos antiguos: archivos subidos con otra clave IAM, otra política o una configuración distinta del bucket. Eso puede explicar por qué unos medios funcionan y otros no.
Cómo revisar credenciales IAM, bucket y región paso a paso
- Identifica la acción que falla. Comprueba si el error aparece al subir medios a S3 desde WordPress, al regenerar miniaturas, al servir URLs o al borrar adjuntos. Esto orienta los permisos que suelen hacer falta.
- Verifica las credenciales activas. Revisa qué usuario o rol IAM usa el plugin y confirma que la clave no esté caducada, rotada o mal configurada. Una credencial antigua puede provocar acceso denegado al bucket aunque el resto parezca correcto.
- Confirma bucket y región. Un bucket correcto en una región equivocada puede causar errores de acceso o redirecciones que el plugin no resuelve como esperas.
- Revisa la política del bucket y el bloqueo de acceso público. Si el plugin necesita escribir o leer objetos, una política demasiado restrictiva puede bloquear la operación aunque IAM permita el acceso.
- Comprueba la configuración del plugin. Ajustes como borrar archivos locales, servir desde S3 o CloudFront, mover objetos o rutas personalizadas pueden cambiar las operaciones que intenta hacer WP Offload Media.
Antes de aplicar cambios en IAM o en permisos bucket S3, conviene contrastarlos con la documentación oficial de AWS y del plugin, especialmente si trabajas en producción.
Qué permisos pueden hacer falta según cómo uses Offload Media
El mínimo necesario depende de cómo uses el plugin. De forma orientativa, suele requerirse acceso para listar el bucket o prefijos, subir objetos, leer objetos, copiar o mover archivos y, si está activado, eliminar objetos.
- Fallo al subir: suele apuntar a permisos IAM S3 insuficientes para escribir objetos o a bucket policy restrictiva.
- Fallo al servir URLs: puede deberse a lectura denegada, URLs firmadas mal planteadas, CDN, bloqueo público o rutas inconsistentes.
- Errores al copiar archivos a S3: conviene revisar permisos de lectura sobre el origen y escritura sobre el destino, además de ajustes de renombrado o prefijos.
- Fallo al eliminar: puede indicar que el usuario IAM puede subir, pero no borrar objetos ya existentes.
Si tu bucket usa Object Ownership con ACL desactivadas, algunas integraciones antiguas pueden necesitar revisión. No siempre falla, pero sí puede afectar a objetos heredados o a expectativas del plugin sobre la propiedad de los archivos.
Errores frecuentes que conviene descartar antes de cambiar políticas
- Bucket correcto, pero región errónea en el plugin.
- Credenciales mal configuradas en wp-config.php, variables de entorno o panel del servidor.
- Diferencias entre objetos nuevos y antiguos por cambios de propietario o políticas previas.
- Bloqueo de acceso público activo cuando se pretende servir archivos públicamente desde S3.
- CloudFront o CDN entregando respuestas cacheadas que confunden el diagnóstico.
- Cambios recientes en rutas, prefijos o dominio de entrega que hacen parecer que hay permisos insuficientes en S3.
Qué hacer si el fallo persiste tras revisar la configuración
Si después de revisar IAM, bucket, región y plugin el problema sigue, lo más útil es apoyarte en evidencias. Consulta los logs de WordPress, del servidor y, si tu entorno lo permite, los eventos relacionados con S3 e IAM para ver qué acción concreta se deniega.
Lista rápida de comprobación
- ¿La clave IAM activa es la correcta y sigue vigente?
- ¿El bucket y la región coinciden exactamente con la configuración?
- ¿La política del bucket permite la operación concreta?
- ¿El fallo afecta a subir, leer, copiar o borrar?
- ¿Hay objetos antiguos con permisos o propiedad diferentes?
Como referencia oficial, conviene revisar la documentación de Amazon S3 e IAM antes de tocar políticas en producción, ya que el mínimo de permisos depende del flujo real de tu instalación.
En resumen: si los permisos S3 fallan con Offload Media, el diagnóstico debe empezar por identificar la operación afectada y validar credenciales IAM, bucket, región y acceso a objetos. Haz los cambios con cautela, mejor en staging si es posible, y como siguiente paso razonable revisa logs detallados o pide ayuda técnica especializada si el entorno mezcla WordPress, S3 y CDN.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.