Corriger les erreurs d'authentification Backblaze B2 — NetDrive
Résoudre les échecs de connexion Backblaze B2 dans NetDrive causés par des clés d'application limitées à un bucket, des clés expirées et des paires de clés mal associées.
Un lecteur Backblaze B2 qui se montait sans problème le mois dernier renvoie soudain une erreur d’authentification, ou une toute nouvelle connexion rejette des identifiants copiés-collés directement depuis la console Backblaze. Dans les deux cas, la cause remonte généralement au fonctionnement des clés d’application B2 plutôt qu’à un problème du compte lui-même — les clés B2 comportent des restrictions et des dates d’expiration qu’une simple connexion identifiant-mot de passe n’a pas.
Monter Backblaze B2 comme lettre de lecteur
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.
- Téléversements multipart pour les fichiers d'archive volumineux
- Les téléversements en arrière-plan gardent le lecteur réactif pendant les transferts
- Disponible sur Windows, macOS et Linux (expérimental)
Essai gratuit. Licences à vie et abonnements disponibles.
Associer l’erreur à une cause
Backblaze B2 prend en charge les connexions NetDrive depuis la version 3.5.434, et presque tous les échecs d’authentification correspondent à l’un de ces schémas :
| Symptôme | Cause la plus probable |
|---|---|
| « Access denied » ou « unauthorized » nommant un bucket précis | La clé d’application est restreinte à un bucket différent de celui saisi |
| Des identifiants qui fonctionnaient auparavant échouent soudainement | La clé d’application a expiré ou a été supprimée dans la console Backblaze |
| Le keyID et la key copiés-collés sont rejetés d’emblée | Un espace superflu, un collage tronqué, ou la mauvaise paire copiée depuis une liste de plusieurs clés |
Correction 1 : vérifier la restriction de bucket de la clé d’application
Backblaze permet à un compte de créer plusieurs Application Key en plus de la Master Application Key d’origine, et chaque clé restreinte peut être limitée à un seul bucket pour des raisons de sécurité. C’est la bonne pratique — une connexion NetDrive dédiée à un seul bucket ne devrait pas détenir une clé disposant d’un accès à l’échelle du compte — mais cela signifie aussi que le nom du bucket saisi dans NetDrive doit correspondre exactement au bucket pour lequel la clé a été créée, sinon la connexion échoue avec une erreur qui ressemble à des identifiants invalides.
Connectez-vous à la console Backblaze B2 et vérifiez le paramètre Allowed Bucket(s) de la clé. S’il indique un bucket précis, vérifiez que ce nom correspond exactement à celui saisi comme bucket dans la configuration du lecteur NetDrive — la casse et les traits d’union comptent, car les noms de bucket B2 sont sensibles à la casse.
Correction 2 : régénérer une clé expirée ou supprimée
Les clés d’application dans B2 peuvent être créées avec une date d’expiration, et une fois cette date passée, la clé cesse de s’authentifier sans aucun avertissement dans NetDrive lui-même — le lecteur ne peut tout simplement plus se connecter. Il en va de même si une clé a été supprimée ou révoquée directement dans la console Backblaze, ce qui se présente de manière identique à une expiration du point de vue de NetDrive.
- Dans la console Backblaze, créez une nouvelle Application Key (ou vérifiez si la clé existante apparaît comme expirée/supprimée).
- Copiez immédiatement les nouveaux keyID et applicationKey — Backblaze n’affiche la clé d’application complète qu’une seule fois, au moment de la création.
- Dans NetDrive, ouvrez Drive Manager, sélectionnez le lecteur B2, cliquez sur Edit, et remplacez les champs keyID et applicationKey par les nouvelles valeurs.
- Cliquez sur Connect pour vous authentifier à nouveau.
Correction 3 : ressaisir les identifiants plutôt que de copier-coller des fragments
Comme les clés d’application B2 sont de longues chaînes générées aléatoirement, une erreur fréquente consiste à ne copier qu’une partie de la clé — un triple-clic qui manque un caractère final, ou un collage qui récupère un saut de ligne parasite. Backblaze n’affichant l’applicationKey complet qu’une seule fois, il est impossible de vérifier après coup une copie enregistrée par rapport à la console.
Si les identifiants échouent immédiatement après la configuration et que la restriction de bucket comme la date d’expiration sont correctes, la solution la plus sûre est de générer une toute nouvelle clé d’application plutôt que de tenter de déboguer une clé potentiellement tronquée :
- Supprimez l’ancienne clé dans la console Backblaze.
- Créez une nouvelle Application Key, limitée au bon bucket.
- Collez d’abord le keyID et l’applicationKey dans un champ de texte brut pour confirmer l’absence d’espaces ou de sauts de ligne, puis saisissez-les dans les champs de connexion de NetDrive.
Si rien de tout cela ne s’applique
Si la restriction de bucket correspond, que la clé n’est pas expirée, et qu’une clé fraîchement générée échoue toujours, vérifiez que le compte lui-même n’a pas de blocage lié à un paiement ou à une vérification — B2 peut rejeter les appels API au niveau du compte indépendamment de la validité d’une clé individuelle, ce qui se traduit dans NetDrive par la même erreur d’authentification générique.
En résumé
La plupart des échecs d’authentification Backblaze B2 dans NetDrive se résument à une clé restreinte pointant vers le mauvais bucket, une clé expirée ou supprimée, ou un copier-coller corrompu de la longue chaîne applicationKey. Pour la configuration initiale sur laquelle s’appuie ce dépannage, voir Monter Backblaze B2 sous Windows avec NetDrive ou Monter Backblaze B2 sous macOS avec NetDrive. Si une configuration de stockage objet similaire utilise Amazon S3, Corriger les erreurs Access Denied S3 dans NetDrive couvre le volet permissions IAM équivalent du même problème.
— Kai, NetDrive