Corriger l'erreur Connexion refusée MinIO — NetDrive
NetDrive n'atteint pas votre endpoint MinIO auto-hébergé ? Voici les trois causes les plus courantes d'une erreur Connexion refusée : mauvais port, pare-feu fermé et confusion console/API.
Vous pointez NetDrive vers votre cluster MinIO auto-hébergé, cliquez sur Test, et au lieu d’une coche verte vous obtenez « Connection refused ». Le bucket ne se monte jamais, et l’erreur n’indique pas si le problème vient de l’endpoint, des identifiants ou du chemin réseau entre les deux. C’est presque toujours l’une de ces trois choses : le mauvais port, un pare-feu fermé, ou l’URL de la console confondue avec l’URL de l’API.

Monter du stockage S3-compatible auto-hébergé comme un 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.
- Se connecte à MinIO et à tout endpoint S3-compatible
- Le bouton Test vérifie la connectivité avant de monter
- Fonctionne sur Windows et macOS avec les mêmes champs de connexion
Essai gratuit. Licences à vie et abonnements disponibles.
Pourquoi « Connection Refused » est une erreur réseau, pas une erreur d’identifiants
« Connection refused » survient avant même que NetDrive ne vérifie votre Access Key ou votre Secret Key. La connexion TCP vers l’endpoint lui-même est rejetée — rien n’écoute à l’adresse et au port tentés par NetDrive, ou quelque chose entre votre machine et le serveur MinIO bloque activement la connexion. C’est un mode d’échec différent d’« Access Denied », qui signifie que NetDrive a bien atteint MinIO et que MinIO a refusé. Si vous voyez « Connection refused », réglez d’abord le chemin réseau ; les problèmes d’identifiants ne peuvent même pas apparaître tant que cette couche ne fonctionne pas.

Vérification 1 : port de la console vs. port de l’API
MinIO fait tourner deux services séparés sur deux ports séparés : l’API S3 (par défaut 9000) et la Console web (par défaut 9001). NetDrive a besoin du port de l’API — pointer le champ Endpoint vers le port de la Console produit une connexion qui soit refuse purement, soit se connecte au mauvais service.
- Ouvrez NetDrive → cliquez sur l’icône d’engrenage du lecteur MinIO pour ouvrir ses paramètres.
- Confirmez que le champ Endpoint ressemble à
http://192.168.1.50:9000, et non:9001. - Si vous n’êtes pas sûr du port utilisé par votre instance MinIO pour l’API, vérifiez la variable d’environnement
MINIO_API_PORTou le flag--addressutilisé au démarrage du serveur — la Console possède généralement son propre flag--console-address.
Vérification 2 : pare-feu et publication des ports Docker
Si le port est correct et que vous obtenez toujours « Connection refused », quelque chose entre NetDrive et l’hôte MinIO bloque la connexion.
- Déploiements Docker : confirmez que le conteneur publie bien le port —
docker run -p 9000:9000 ...ou l’équivalent dans votre fichier compose. Un conteneur MinIO tournant sans port publié est inaccessible depuis l’extérieur de l’hôte, même s’il paraît sain dansdocker ps. - Pare-feu de l’hôte : sous Linux, vérifiez
ufw statusouiptables -Lpour une règle bloquant le port 9000 entrant. Sous Windows Server hébergeant MinIO, vérifiez les règles entrantes du Pare-feu Windows Defender. - Segmentation réseau : si NetDrive tourne sur un VLAN ou sous-réseau différent de l’hôte MinIO, confirmez que le routage entre eux autorise le port — un écart fréquent dans les bureaux où les serveurs se trouvent sur un segment distinct des postes de travail.

Un moyen rapide d’isoler si le problème vient de NetDrive ou du réseau : depuis la même machine, ouvrez un navigateur et allez à http://<endpoint>:9000/minio/health/live. Si le navigateur ne peut pas non plus se connecter, le problème est entièrement dans le chemin réseau, pas dans la configuration de NetDrive.
Vérification 3 : endpoint HTTPS avec certificat auto-signé
Si votre endpoint MinIO utilise https:// derrière un reverse proxy avec un certificat auto-signé ou d’une CA interne, certains échecs de handshake TLS apparaissent comme un échec de connexion générique plutôt qu’un avertissement de certificat. Confirmez que la chaîne de certificats est valide depuis la machine exécutant NetDrive — pour une CA interne, cette machine a besoin du certificat de la CA installé dans son magasin de confiance. Comme étape de diagnostic, testez temporairement avec http:// sur le réseau interne pour confirmer que l’endpoint et le port sont par ailleurs corrects, puis réactivez HTTPS une fois le certificat approuvé.

Retester la connexion
Une fois le port, le pare-feu et le certificat réglés :
- Ouvrez NetDrive → sélectionnez le lecteur MinIO dans le Drive Manager.
- Ressaisissez l’Endpoint, confirmez que Path style est activé (MinIO auto-hébergé en a presque toujours besoin plutôt que l’adressage virtual-hosted), et cliquez sur Test.
- Une coche verte signifie que les couches TCP et TLS fonctionnent — si le lecteur ne se monte toujours pas après ça, le problème restant est presque toujours lié aux identifiants ou aux permissions du bucket plutôt qu’à la connectivité.
Pour conclure
« Connection refused » sur un lecteur MinIO est presque toujours un problème de couche réseau : mauvais port, une règle de pare-feu ou de publication Docker bloquant l’accès, ou un certificat non approuvé sur un endpoint HTTPS. Travaillez d’abord le port et le pare-feu — ils expliquent la majorité des cas — avant de suspecter les identifiants. Pour le guide de configuration complet, voir Monter MinIO sur Windows avec NetDrive ou Monter MinIO sur macOS avec NetDrive. Si la connexion réussit mais que l’accès est refusé ensuite, Corriger les erreurs S3 Access Denied avec NetDrive couvre le volet identifiants et politiques.
— Steve, NetDrive