Corregir el error Access Denied de S3 al montar Amazon S3 — NetDrive

Montas un bucket de S3 en NetDrive, la letra de unidad aparece en el Explorador de Windows y luego cada operación de archivo devuelve “Access Denied”. La unidad aparece pero nada es accesible. Esto ocurre cuando las credenciales IAM que usa NetDrive carecen de las acciones S3 necesarias, o cuando la política IAM es correcta pero una política de bucket la está anulando.

Monta buckets de S3 como unidad local

NetDrive hace que Google Drive, OneDrive, S3, SFTP, WebDAV y más aparezcan como unidades nativas en Windows y macOS — sin sincronizar, sin descargas completas.

• Compatible con Amazon S3 y almacenamiento compatible con S3 (Wasabi, MinIO y más)
• El explorador de archivos te permite probar el acceso al bucket antes de montar
• Detección automática de región S3 desde NetDrive 3.19.7

WindowsmacOS

Descargar NetDrive →

Prueba gratuita. Planes de por vida y de suscripción disponibles.

Por qué aparece Access Denied en una unidad S3 montada

El acceso a Amazon S3 está regido por dos capas independientes: la política IAM adjunta al usuario o rol cuyas claves de acceso introdujiste, y la política de bucket adjunta al propio bucket. Cualquiera de las dos capas puede denegar una operación sin que la otra lo sepa.

NetDrive necesita al menos estas acciones S3 para montar y trabajar con un bucket con normalidad:

• s3:ListBucket — para listar objetos y construir las vistas de directorio
• s3:GetObject — para leer el contenido de un archivo al abrirlo
• s3:PutObject — para escribir archivos de vuelta al bucket (solo montajes de lectura-escritura)
• s3:DeleteObject — para eliminar archivos desde la unidad montada (solo montajes de lectura-escritura)

Una acción faltante provoca “Access Denied” en esa operación concreta. Puede que puedas explorar el directorio pero se te deniegue al abrir un archivo, o que puedas abrir archivos pero se te deniegue al guardar — ambos son síntomas de un permiso IAM parcial, no de un fallo total de credenciales.

Comprobación 1: credenciales introducidas en NetDrive

Empieza por las propias credenciales. Un solo carácter transpuesto en la clave de acceso o una clave secreta obsoleta producen los mismos síntomas de “Access Denied” que una política IAM mal configurada.

1. Open NetDrive → haz clic en el icono de engranaje de tu unidad S3 para abrir su configuración.
2. Compara el Access Key ID carácter por carácter con el valor mostrado en la consola de AWS en IAM → Users → [username] → Security credentials. Cópialo y pégalo en lugar de volver a escribirlo.
3. Vuelve a introducir la Secret Access Key. AWS nunca vuelve a mostrar este valor tras la creación inicial, así que si hay alguna duda sobre su corrección, genera un nuevo par de claves en IAM y actualiza NetDrive con los nuevos valores de inmediato.
4. Revisa el campo Region. Un desajuste de región — por ejemplo, configurar us-east-1 cuando tu bucket está en eu-west-1 — dirige las solicitudes al endpoint equivocado y devuelve errores 403. NetDrive 3.19.7 añadió la detección automática de región en las conexiones nuevas, pero las configuraciones de unidad creadas antes de la actualización siguen conservando el valor introducido originalmente. Actualiza la región manualmente si es necesario.

Tras corregir cualquier problema de credenciales, haz clic en Mount e intenta explorar un directorio antes de continuar con la capa IAM.

Comprobación 2: política IAM — acciones S3 necesarias

Si las credenciales son correctas pero el acceso sigue siendo rechazado, a la política IAM adjunta le faltan una o más acciones necesarias. La forma más rápida de confirmarlo es el AWS IAM Policy Simulator.

En la consola de AWS, ve a IAM → Policy Simulator, selecciona el usuario IAM cuyas claves están en NetDrive, y prueba s3:ListBucket contra el ARN de tu bucket (arn:aws:s3:::my-bucket) y s3:GetObject contra el ARN de los objetos (arn:aws:s3:::my-bucket/*). Si el simulador devuelve “Denied”, añade una política que otorgue las acciones faltantes.

Una política mínima para acceso de lectura-escritura a un único bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Observa los dos valores Resource separados: ListBucket se aplica al propio ARN del bucket, mientras que GetObject, PutObject y DeleteObject se aplican a los objetos dentro de él (/*). Combinarlos en una sola línea Resource es un error común que rompe silenciosamente el listado o el acceso a los objetos.

Usa el File Browser de NetDrive (accesible sin montar) para verificar rápidamente si el acceso a los objetos funciona tras actualizar la política IAM. Emite las mismas llamadas API que una unidad montada pero sin asignar una letra de unidad, lo que lo convierte en un ciclo de retroalimentación rápido durante la resolución de problemas.

Comprobación 3: denegaciones explícitas en la política de bucket

Una política IAM permisiva queda anulada por un Deny explícito en la política de bucket. Ve a S3 → [your bucket] → Permissions → Bucket policy y busca cualquier sentencia "Effect": "Deny". Los culpables habituales incluyen:

• Restricciones de endpoint de VPC — políticas que deniegan solicitudes que no se originan desde un endpoint de VPC específico (aws:SourceVpc). NetDrive de escritorio se conecta por internet público a menos que enrutes a través de una VPN.
• Listas blancas de IP — políticas que usan aws:SourceIp y bloquean solicitudes desde la IP pública de tu máquina.
• Denegaciones HTTP — una sentencia que deniega solicitudes cuando aws:SecureTransport es false. Esto normalmente es inofensivo porque NetDrive usa HTTPS para las solicitudes S3 (verificado desde la versión 3.1.234), pero vale la pena comprobarlo si una política de bucket se escribió de forma defensiva.

Si encuentras una condición restrictiva que se aplica a tu patrón de acceso, relaja la condición o añade el usuario IAM a un Allow explícito que tenga precedencia.

Resumen

Los errores “Access Denied” de S3 en NetDrive casi siempre se remontan a una de tres causas: credenciales incorrectas, una política IAM a la que le falta una acción necesaria, o una política de bucket con una denegación explícita. Recórrelas en ese orden — las credenciales son lo más rápido de descartar. Para montar otros proveedores de almacenamiento de objetos, consulta mounting Amazon S3 on macOS o el DevOps S3 fixture workflow with NetDrive.

— Casey, NetDrive