S3-Zugriffsfehler beim Einbinden in NetDrive beheben

Sie binden einen S3-Bucket in NetDrive ein, der Laufwerksbuchstabe erscheint im Windows Explorer, und danach liefert jede Dateioperation „Access Denied”. Das Laufwerk wird angezeigt, aber nichts ist zugänglich. Das passiert, wenn den IAM-Zugangsdaten, die NetDrive verwendet, die nötigen S3-Aktionen fehlen — oder wenn die IAM-Policy korrekt ist, aber eine Bucket-Policy sie überschreibt.

S3-Buckets als lokales Laufwerk einbinden

Mit NetDrive erscheinen Google Drive, OneDrive, S3, SFTP, WebDAV und mehr als native Laufwerke unter Windows und macOS — ohne Synchronisation, ohne vollständige Downloads.

• Unterstützt Amazon S3 und S3-kompatiblen Speicher (Wasabi, MinIO und mehr)
• Mit dem Dateibrowser den Bucket-Zugriff vor dem Einbinden testen
• Automatische S3-Regionserkennung seit NetDrive 3.19.7

WindowsmacOS

NetDrive herunterladen →

Kostenlose Testversion. Lifetime- und Abo-Pläne verfügbar.

Warum „Access Denied” bei einem eingebundenen S3-Laufwerk erscheint

Der Zugriff auf Amazon S3 wird von zwei unabhängigen Ebenen geregelt: der IAM-Policy, die an den Benutzer oder die Rolle geknüpft ist, deren Zugriffsschlüssel Sie eingegeben haben, und der Bucket-Policy, die am Bucket selbst hängt. Jede Ebene kann eine Operation verweigern, ohne dass die andere davon weiß.

NetDrive benötigt mindestens diese S3-Aktionen, um einen Bucket normal einzubinden und zu nutzen:

• s3:ListBucket — um Objekte aufzulisten und Verzeichnisansichten aufzubauen
• s3:GetObject — um Dateiinhalte zu lesen, wenn Sie eine Datei öffnen
• s3:PutObject — um Dateien in den Bucket zurückzuschreiben (nur bei Lese-Schreib-Mounts)
• s3:DeleteObject — um Dateien vom eingebundenen Laufwerk zu löschen (nur bei Lese-Schreib-Mounts)

Eine fehlende Aktion verursacht „Access Denied” bei genau dieser Operation. Möglicherweise können Sie das Verzeichnis durchsuchen, aber bekommen beim Öffnen einer Datei eine Fehlermeldung, oder Sie können Dateien öffnen, aber nicht speichern — beides sind Symptome einer unvollständigen IAM-Freigabe, nicht eines vollständigen Zugangsdatenfehlers.

Check 1: In NetDrive eingegebene Zugangsdaten

Beginnen Sie mit den Zugangsdaten selbst. Ein einziges vertauschtes Zeichen im Zugriffsschlüssel oder ein veralteter geheimer Schlüssel erzeugt dieselben „Access Denied”-Symptome wie eine falsch konfigurierte IAM-Policy.

1. Open NetDrive → klicken Sie auf das Zahnradsymbol Ihres S3-Laufwerks, um dessen Einstellungen zu öffnen.
2. Vergleichen Sie die Access Key ID Zeichen für Zeichen mit dem Wert in der AWS-Konsole unter IAM → Users → [Benutzername] → Security credentials. Kopieren und einfügen statt neu eintippen.
3. Geben Sie den Secret Access Key erneut ein. AWS zeigt diesen Wert nach der ersten Erstellung nie wieder an — bestehen also Zweifel an seiner Richtigkeit, erzeugen Sie in IAM ein neues Schlüsselpaar und tragen Sie die neuen Werte sofort in NetDrive ein.
4. Prüfen Sie das Feld Region. Eine falsche Region — zum Beispiel us-east-1 konfiguriert, während Ihr Bucket in eu-west-1 liegt — leitet Anfragen an den falschen Endpunkt und liefert 403-Fehler. NetDrive 3.19.7 hat automatische Regionserkennung für neue Verbindungen eingeführt, aber Laufwerkskonfigurationen, die vor dem Update erstellt wurden, behalten weiterhin den ursprünglich eingegebenen Wert. Aktualisieren Sie die Region bei Bedarf manuell.

Nachdem Sie eventuelle Zugangsdatenprobleme behoben haben, klicken Sie auf Mount und versuchen Sie, ein Verzeichnis zu durchsuchen, bevor Sie mit der IAM-Ebene fortfahren.

Check 2: IAM-Policy — erforderliche S3-Aktionen

Wenn die Zugangsdaten korrekt sind, der Zugriff aber weiterhin verweigert wird, fehlen der zugehörigen IAM-Policy eine oder mehrere erforderliche Aktionen. Der schnellste Weg, das zu bestätigen, ist der AWS IAM Policy Simulator.

Gehen Sie in der AWS-Konsole zu IAM → Policy Simulator, wählen Sie den IAM-Benutzer, dessen Schlüssel in NetDrive hinterlegt sind, und testen Sie s3:ListBucket gegen Ihre Bucket-ARN (arn:aws:s3:::my-bucket) sowie s3:GetObject gegen die Objekt-ARN (arn:aws:s3:::my-bucket/*). Meldet der Simulator „Denied”, fügen Sie eine Policy hinzu, die die fehlenden Aktionen gewährt.

Eine minimale Policy für Lese-Schreib-Zugriff auf einen einzelnen 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/*"
    }
  ]
}

Beachten Sie die zwei getrennten Resource-Werte: ListBucket gilt für die Bucket-ARN selbst, während GetObject, PutObject und DeleteObject für die Objekte darin gelten (/*). Beide in eine einzige Resource-Zeile zusammenzufassen ist ein häufiger Fehler, der Listing oder Objektzugriff stillschweigend zerstört.

Nutzen Sie NetDrives File Browser (ohne Mounten zugänglich), um nach dem Aktualisieren der IAM-Policy schnell zu prüfen, ob der Objektzugriff funktioniert. Er ruft dieselben API-Aufrufe auf wie ein eingebundenes Laufwerk, jedoch ohne einen Laufwerksbuchstaben zu vergeben — ein schneller Feedback-Kreislauf bei der Fehlersuche.

Check 3: Explizite Deny-Regeln in der Bucket-Policy

Eine großzügige IAM-Policy wird von einem expliziten Deny in der Bucket-Policy überschrieben. Gehen Sie zu S3 → [Ihr Bucket] → Permissions → Bucket policy und suchen Sie nach "Effect": "Deny"-Anweisungen. Häufige Ursachen:

• VPC-Endpoint-Einschränkungen — Policies, die Anfragen ablehnen, die nicht von einem bestimmten VPC-Endpoint stammen (aws:SourceVpc). Desktop-NetDrive verbindet sich über das öffentliche Internet, sofern Sie nicht über ein VPN routen.
• IP-Allowlists — Policies, die mit aws:SourceIp Anfragen von der öffentlichen IP-Adresse Ihres Rechners blockieren.
• HTTP-Deny-Regeln — eine Anweisung, die Anfragen ablehnt, wenn aws:SecureTransport gleich false ist. Das ist normalerweise unproblematisch, da NetDrive für S3-Anfragen HTTPS verwendet (verifiziert seit Version 3.1.234), aber es lohnt sich, das zu prüfen, wenn eine Bucket-Policy defensiv geschrieben wurde.

Finden Sie eine einschränkende Bedingung, die auf Ihr Zugriffsmuster zutrifft, lockern Sie die Bedingung oder fügen Sie den IAM-Benutzer zu einem expliziten Allow hinzu, das Vorrang hat.

Fazit

„Access Denied”-Fehler bei S3 in NetDrive lassen sich fast immer auf eine von drei Ursachen zurückführen: falsche Zugangsdaten, eine IAM-Policy ohne erforderliche Aktion oder eine Bucket-Policy mit explizitem Deny. Arbeiten Sie sie in dieser Reihenfolge ab — Zugangsdaten sind am schnellsten auszuschließen. Für das Einbinden anderer Object-Storage-Anbieter siehe Amazon S3 unter macOS einbinden oder den DevOps-S3-Testfixture-Workflow mit NetDrive.

— Casey, NetDrive