Corriger l'erreur Access Denied S3 dans NetDrive

Vous montez un bucket S3 dans NetDrive, la lettre de lecteur apparaît dans l’Explorateur Windows, puis chaque opération sur les fichiers renvoie « Access Denied ». Le lecteur apparaît mais rien n’est accessible. Cela se produit lorsque les identifiants IAM utilisés par NetDrive manquent des actions S3 requises — ou lorsque la politique IAM est correcte mais qu’une politique de bucket la surcharge.

Montez vos buckets S3 comme un lecteur local

Avec NetDrive, Google Drive, OneDrive, S3, SFTP, WebDAV et plus apparaissent comme des lecteurs natifs sur Windows et macOS — sans synchronisation ni téléchargement complet.

• Prend en charge Amazon S3 et le stockage compatible S3 (Wasabi, MinIO, et plus)
• Le navigateur de fichiers permet de tester l'accès au bucket avant le montage
• Détection automatique de la région S3 depuis NetDrive 3.19.7

WindowsmacOS

Télécharger NetDrive →

Essai gratuit. Licences à vie et abonnements disponibles.

Pourquoi Access Denied apparaît sur un lecteur S3 monté

L’accès à Amazon S3 est régi par deux couches indépendantes : la politique IAM attachée à l’utilisateur ou au rôle dont vous avez saisi les clés d’accès, et la politique de bucket attachée au bucket lui-même. Chacune de ces couches peut refuser une opération sans que l’autre le sache.

NetDrive a besoin d’au moins ces actions S3 pour monter et utiliser un bucket normalement :

• s3:ListBucket — pour lister les objets et construire les vues de répertoires
• s3:GetObject — pour lire le contenu d’un fichier à l’ouverture
• s3:PutObject — pour réécrire des fichiers dans le bucket (lecteurs en lecture-écriture uniquement)
• s3:DeleteObject — pour supprimer des fichiers depuis le lecteur monté (lecteurs en lecture-écriture uniquement)

Une action manquante provoque « Access Denied » sur cette opération précise. Vous pouvez parcourir le répertoire mais être refusé à l’ouverture d’un fichier, ou ouvrir des fichiers mais être refusé à l’enregistrement — ces deux cas révèlent un octroi IAM partiel, pas un échec total des identifiants.

Vérification 1 : identifiants saisis dans NetDrive

Commencez par les identifiants eux-mêmes. Un seul caractère interverti dans la clé d’accès ou une clé secrète périmée produit les mêmes symptômes « Access Denied » qu’une politique IAM mal configurée.

1. Open NetDrive → cliquez sur l’icône d’engrenage de votre lecteur S3 pour ouvrir ses paramètres.
2. Comparez l’Access Key ID caractère par caractère avec la valeur affichée dans la console AWS sous IAM → Users → [username] → Security credentials. Copiez-collez plutôt que de ressaisir.
3. Ressaisissez la Secret Access Key. AWS n’affiche plus jamais cette valeur après sa création initiale ; en cas de doute sur son exactitude, générez une nouvelle paire de clés dans IAM et mettez immédiatement à jour NetDrive avec les nouvelles valeurs.
4. Vérifiez le champ Region. Une région erronée — par exemple us-east-1 configuré alors que votre bucket se trouve dans eu-west-1 — dirige les requêtes vers le mauvais point de terminaison et renvoie des erreurs 403. NetDrive 3.19.7 a ajouté la détection automatique de région pour les nouvelles connexions, mais les lecteurs configurés avant cette mise à jour conservent la valeur saisie à l’origine. Mettez à jour la région manuellement si nécessaire.

Après avoir corrigé les identifiants, cliquez sur Mount et essayez de parcourir un répertoire avant de passer à la couche IAM.

Vérification 2 : politique IAM — actions S3 requises

Si les identifiants sont corrects mais l’accès reste refusé, la politique IAM attachée manque une ou plusieurs actions requises. Le moyen le plus rapide de le confirmer est le Simulateur de politiques IAM d’AWS.

Dans la console AWS, allez dans IAM → Policy Simulator, sélectionnez l’utilisateur IAM dont les clés sont dans NetDrive, puis testez s3:ListBucket sur l’ARN de votre bucket (arn:aws:s3:::my-bucket) et s3:GetObject sur l’ARN des objets (arn:aws:s3:::my-bucket/*). Si le simulateur renvoie « Denied », ajoutez une politique accordant les actions manquantes.

Une politique minimale pour un accès en lecture-écriture à un seul 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/*"
    }
  ]
}

Notez les deux valeurs Resource distinctes : ListBucket s’applique à l’ARN du bucket lui-même, tandis que GetObject, PutObject et DeleteObject s’appliquent aux objets qu’il contient (/*). Les combiner en une seule ligne Resource est une erreur courante qui casse silencieusement le listing ou l’accès aux objets.

Utilisez le File Browser de NetDrive (accessible sans montage) pour vérifier rapidement si l’accès aux objets fonctionne après la mise à jour de la politique IAM. Il émet les mêmes appels API qu’un lecteur monté, mais sans attribuer de lettre de lecteur, ce qui en fait une boucle de rétroaction rapide pendant le dépannage.

Vérification 3 : refus explicites dans la politique de bucket

Une politique IAM permissive est écrasée par un Deny explicite dans la politique de bucket. Allez dans S3 → [your bucket] → Permissions → Bucket policy et recherchez toute instruction "Effect": "Deny". Les cas fréquents incluent :

• Restrictions de point de terminaison VPC — des politiques qui refusent les requêtes ne provenant pas d’un point de terminaison VPC spécifique (aws:SourceVpc). NetDrive sur ordinateur se connecte via l’internet public, sauf si vous passez par un VPN.
• Listes blanches d’IP — des politiques utilisant aws:SourceIp qui bloquent les requêtes provenant de l’adresse IP publique de votre machine.
• Refus HTTP — une instruction qui refuse les requêtes lorsque aws:SecureTransport vaut false. C’est normalement sans conséquence puisque NetDrive utilise HTTPS pour les requêtes S3 (vérifié depuis la version 3.1.234), mais cela vaut la peine d’être vérifié si une politique de bucket a été écrite de façon défensive.

Si vous trouvez une condition restrictive qui s’applique à votre schéma d’accès, assouplissez la condition ou ajoutez l’utilisateur IAM à un Allow explicite qui prend le dessus.

En résumé

Les erreurs « Access Denied » sur S3 dans NetDrive proviennent presque toujours de l’une de ces trois causes : identifiants erronés, politique IAM manquant une action requise, ou politique de bucket avec un refus explicite. Traitez-les dans cet ordre — les identifiants sont les plus rapides à écarter. Pour monter d’autres fournisseurs de stockage objet, consultez monter Amazon S3 sur macOS ou le flux de travail DevOps avec fixtures S3 et NetDrive.

— Casey, NetDrive