Fehlerbehebung

Auf dieser Seite werden Methoden zur Fehlerbehebung für häufige Fehler beschrieben, die bei der Verwendung von Cloud Storage auftreten können.

Im Google Cloud Service Health Dashboard finden Sie Informationen zu Vorfällen, die Google Cloud Dienste wie Cloud Storage betreffen.

Unverarbeitete Anfragen protokollieren

Bei Verwendung von Tools wie gcloud oder den Cloud Storage-Clientbibliotheken werden viele der Anfrage- und Antwortinformationen vom Tool verarbeitet. Manchmal ist es jedoch hilfreich, Details zur Unterstützung bei der Fehlerbehebung anzuzeigen oder Fragen in Foren wie Stack Overflow zu posten. Gehen Sie nach der folgenden Anleitung vor, um Anfrage- und Antwortheader für das Tool zurückzugeben:

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

ruby
Google::Apis.logger.level = Logger::DEBUG

Benutzerdefinierte Header hinzufügen

Das Hinzufügen benutzerdefinierter Header zu Anfragen ist ein gängiges Tool für das Debugging, z. B. zum Aktivieren von Debug-Headern oder zum Tracing einer Anfrage. Im folgenden Beispiel wird gezeigt, wie Sie Anfrageheader für verschiedene Cloud Storage-Tools festlegen:

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

Auf Buckets mit einer CORS-Konfiguration zugreifen

Wenn Sie eine CORS-Konfiguration für Ihren Bucket festgelegt haben und feststellen, dass eingehende Anfragen von Clientbrowsern fehlschlagen, versuchen Sie es mit den folgenden Schritten zur Fehlerbehebung:

1. Prüfen Sie die CORS-Konfiguration des Ziel-Buckets. Wenn Sie mehrere CORS-Konfigurationseinträge haben, achten Sie darauf, dass die für die Fehlerbehebung verwendeten Anfragewerte Werten in einem einzelnen CORS-Konfigurationseintrag zugeordnet sind.

2. Wenn Sie eine CORS-Anfrage testen, achten Sie darauf, dass Sie keine Anfrage an den Endpunkt storage.cloud.google.com stellen, da dieser keine CORS-Anfragen zulässt. Weitere Informationen zu den unterstützten Endpunkten für CORS finden Sie unter CORS-Unterstützung in Cloud Storage.

3. Überprüfen Sie mit dem Tool Ihrer Wahl eine Anfrage und eine Antwort. In einem Chrome-Browser können Sie mit den Standardentwicklertools folgende Informationen ansehen:

   1. Klicken Sie in der Symbolleiste des Browsers auf das Chrome-Menü (more_vert).
   2. Wählen Sie Weitere Tools > Entwicklertools aus.
   3. Klicken Sie auf den Tab Netzwerk.
   4. Senden Sie die Anfrage von Ihrer Anwendung oder Befehlszeile aus.
   5. Suchen Sie die Anfrage im Bereich mit der Netzwerkaktivität.
   6. Klicken Sie in der Spalte Name auf die Anfrage.
   7. Im Tab Header werden die Antwortheader angezeigt. Unter Antwort sehen Sie den Inhalt der Antwort.

   Wenn Sie keine Anfrage und keine Antwort sehen, ist im Browsercache wahrscheinlich noch ein früherer fehlgeschlagener Preflight-Anfrageversuch gespeichert. Wenn Sie den Browsercache löschen, sollte auch der Preflight-Cache geleert werden. Ist dies nicht der Fall, legen Sie für MaxAgeSec in Ihrer CORS-Konfiguration einen niedrigeren Wert als den Standardwert von 1800 (30 Minuten) fest. Warten Sie dann die vorherige Zeitspanne MaxAgeSec ab und wiederholen Sie die Anfrage. Dadurch wird eine neue Preflight-Anfrage ausgeführt. Diese ruft die neue CORS-Konfiguration ab und löscht die Cache-Einträge. Erhöhen Sie den Wert für MaxAgeSec nach Beheben des Fehlers wieder, um den Preflight-Traffic zum Bucket zu reduzieren.

4. Prüfen Sie, ob die Anfrage den Header Origin enthält und der Headerwert mindestens einem der Werte für Origins in der CORS-Konfiguration des Buckets entspricht. Das Schema, der Host und der Port der Werte müssen exakt übereinstimmen. Hier einige Beispiele für zulässige Übereinstimmungen:

   • http://origin.example.com entspricht http://origin.example.com:80, weil 80 der standardmäßige HTTP-Port ist, stimmt aber nicht mit https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 oder http://sub.origin.example.com überein.

   • https://example.com:443 entspricht https://example.com, aber nicht http://example.com oder http://example.com:443.

   • http://localhost:8080 entspricht nur genau http://localhost:8080, aber nicht http://localhost:5555 oder http://localhost.example.com:8080.

5. Prüfen Sie bei einfachen Anfragen, ob die HTTP-Methode der Anfrage mindestens einem der Werte für Methods in der CORS-Konfiguration des Buckets entspricht. Prüfen Sie bei Preflight-Anfragen, ob die in Access-Control-Request-Method angegebene Methode mindestens einem der Werte für Methods entspricht.

6. Prüfen Sie bei Preflight-Anfragen, ob diese einen oder mehrere Header der Form Access-Control-Request-Header enthält. Wenn ja, achten Sie darauf, dass jeder Wert für Access-Control-Request-Header einem Wert für ResponseHeader in der CORS-Konfiguration des Buckets entspricht. Alle im Access-Control-Request-Header enthaltenen Header müssen in der CORS-Konfiguration der Preflight-Anfrage enthalten sein, damit diese ausgeführt werden kann und CORS-Header in die Antwort aufgenommen werden.

Fehlercodes

Nachfolgend sehen Sie einige gängige HTTP-Statuscodes.

301: Dauerhaft verschoben

Problem: Ich bin dabei, eine statische Website einzurichten, und beim Zugriff auf einen Verzeichnispfad wird ein leeres Objekt und der HTTP-Antwortcode 301 zurückgegeben.

Lösung: Wenn beim Zugriff auf ein Verzeichnis, z. B. http://www.example.com/dir/, ein Nullbyte-Objekt vom Browser heruntergeladen wird und Sie den HTTP-Antwortcode 301 erhalten, enthält Ihr Bucket sehr wahrscheinlich ein leeres Objekt mit diesem Namen. Prüfen Sie, ob dies der Fall ist, und beheben Sie das Problem:

1. Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.
   

   Buckets aufrufen

2. Klicken Sie oben in der Konsole auf die Schaltfläche Cloud Shell aktivieren. Google Cloud
3. Führen Sie gcloud storage ls --recursive gs://www.example.com/dir/ aus. Wenn die Ausgabe http://www.example.com/dir/ enthält, ist an diesem Speicherort ein leeres Objekt vorhanden.
4. Entfernen Sie das leere Objekt mit dem folgenden Befehl: gcloud storage rm gs://www.example.com/dir/

Sie können nun auf http://www.example.com/dir/ zugreifen und die index.html-Datei dieses Verzeichnisses anstelle des leeren Objekts zurückgeben lassen.

400: Ungültige Anfrage

Problem: Bei einem fortsetzbaren Upload habe ich diesen Fehler und die Meldung Failed to parse Content-Range header. erhalten.

Lösung: Der Wert, den Sie im Header Content-Range verwendet haben, ist ungültig. Content-Range: */* ist beispielsweise ungültig und sollte als Content-Range: bytes */* angegeben werden. Wenn Sie diesen Fehler erhalten, ist Ihr aktueller fortsetzbarer Upload nicht mehr aktiv und Sie müssen einen neuen fortsetzbaren Upload starten.

400: Storage Intelligence-spezifische Fehler

In den folgenden Abschnitten werden häufige Fehler beschrieben, die beim Konfigurieren oder Verwalten von Storage Intelligence für eine Ressource auftreten können.

400: Ungültiger Bucket-Name

Problem: Wenn Sie Storage Intelligence für eine Ressource konfigurieren oder verwalten, erhalten Sie möglicherweise diesen Fehler und die Meldung The specific bucket is not valid..

Lösung: Die URL, die Sie in der Anfrage verwendet haben, ist ungültig. Die URL muss die folgenden Anforderungen erfüllen:

• locations/global ist der einzige unterstützte Standort für Storage Intelligence. Die Verwendung anderer Standorte wird nicht unterstützt.
• Storage Intelligence ist in der URL im Singular, nicht im Plural.

Hier ist ein Beispiel für eine gültige URL:

curl -X PATCH -H "Content-Type: application/json" -d
    '{"edition_config": "STANDARD" }'
    -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.googleapis.com/v2/projects/my-project/locations/global/storageIntelligence?updateMask=edition_config"

400: Ungültiges Argument – leere Aktualisierungsmaske

Problem: Wenn Sie Storage Intelligence für eine Ressource konfigurieren oder verwalten, erhalten Sie möglicherweise diesen Fehler und die Meldung Empty UPDATE_MASK in the request..

Lösung: UPDATE_MASK ist die durch Kommas getrennte Liste der Feldnamen, die durch die Anfrage aktualisiert werden. Die Feldnamen verwenden das Format FieldMask und sind Teil der Ressource StorageIntelligence. Wenn Sie die Storage Intelligence-Konfiguration einer Ressource aktualisieren möchten, verwenden Sie eine gültige UPDATE_MASK in der Anfrage. Ein leerer Wert wird nicht unterstützt.

400: Ungültiger Aktualisierungsmaskenpfad

Problem: Wenn Sie Storage Intelligence für eine Ressource konfigurieren oder verwalten, erhalten Sie möglicherweise diesen Fehler und die Meldung Invalid UPDATE_MASK paths..

Lösung: Wenn Sie im UPDATE_MASK einen ungültigen Feldnamen verwenden, erhalten Sie eine Fehlermeldung. UPDATE_MASK ist die durch Kommas getrennte Liste der Feldnamen, die durch die Anfrage aktualisiert werden. Die Feldnamen verwenden das Format FieldMask und sind Teil der Ressource IntelligenceConfig. Wenn Sie die Storage Intelligence-Konfiguration einer Ressource aktualisieren möchten, muss jeder Feldname, der in UPDATE_MASK aufgeführt ist, ein gültiges Feld in der Ressource IntelligenceConfig sein.

400: Feld kann nicht bearbeitet werden

Problem: Wenn Sie Storage Intelligence für eine Ressource konfigurieren oder verwalten, erhalten Sie möglicherweise diesen Fehler und die Meldung Invalid UPDATE_MASK: UPDATE_TIME field is not editable..

Lösung: UPDATE_MASK ist die durch Kommas getrennte Liste der Feldnamen, die durch die Anfrage aktualisiert werden. Die Feldnamen verwenden das Format FieldMask und sind Teil der Ressource IntelligenceConfig. Wenn Sie versuchen, ein Feld zu aktualisieren, das nicht bearbeitet werden kann, erhalten Sie eine Fehlermeldung. Entfernen Sie das nicht bearbeitbare Feld aus Update_Mask und versuchen Sie es noch einmal.

400: Ungültiger Wert

Problem: Wenn Sie Storage Intelligence für eine Ressource konfigurieren oder verwalten, erhalten Sie möglicherweise diesen Fehler und die Meldung Invalid value at storage_intelligence.edition_config..

Lösung: Wenn Sie versuchen, einen ungültigen Wert für das Feld edition_config zu verwenden, erhalten Sie eine Fehlermeldung. Die zulässigen Werte sind INHERIT, STANDARD und DISABLED. Prüfen Sie den Wert und versuchen Sie es noch einmal.

400: Nicht leerer Filter

Problem: Wenn Sie die Storage Intelligence-Konfiguration für eine Ressource aktualisieren, erhalten Sie möglicherweise diesen Fehler und die Meldung Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration..

Lösung: Wenn Sie die Storage Intelligence-Version edition_config auf INHERIT oder DISABLED aktualisieren, können Sie in der Anfrage keine Bucket-Filter verwenden. Entfernen Sie die Filter aus der Anfrage und versuchen Sie es noch einmal.

400: Leere Standort- oder Bucket-Werte im Filter

Problem: Wenn Sie die Storage Intelligence-Konfiguration für eine Ressource aktualisieren, erhalten Sie möglicherweise diesen Fehler und die Meldung Empty location or bucket values in filter..

Lösung: Wenn Sie die Storage Intelligence-Konfiguration aktualisieren und in der Anfrage einen Bucket-Filter verwenden, tritt ein Fehler auf, wenn der Wert von location oder bucket ein leerer String ist. Geben Sie einen gültigen Wert für location oder bucket an und versuchen Sie es noch einmal.

401: Nicht autorisiert

Problem: Anfragen an einen öffentlichen Bucket direkt oder über Cloud CDN schlagen mit den Antworten HTTP 401: Unauthorized und Authentication Required fehl.

Lösung: Achten Sie darauf, dass Ihr Client oder ein Zwischen-Proxy Anfragen an Cloud Storage keinen Authorization-Header hinzufügt. Jede Anfrage mit einem Authorization-Header wird überprüft, als wenn es sich um einen Authentifizierungsversuch handeln würde, selbst wenn die Anfrage leer ist.

403: Konto deaktiviert

Problem: Ich habe versucht, einen Bucket zu erstellen, erhalte jedoch den Fehler 403 Account Disabled.

Lösung: Dieser Fehler weist darauf hin, dass Sie die Abrechnung für das verknüpfte Projekt noch nicht aktiviert haben. Wie Sie vorgehen müssen, um die Abrechnung zu aktivieren, erfahren Sie unter Abrechnung für ein Projekt aktivieren.

Wenn die Abrechnung aktiviert ist und Sie weiterhin diese Fehlermeldung erhalten, wenden Sie sich an den Support. Geben Sie dabei Ihre Projekt-ID und eine Beschreibung des Problems an.

403: Unzulässig

Problem: Ich sollte die Berechtigung haben, auf einen bestimmten Bucket oder ein bestimmtes Objekt zuzugreifen. Wenn ich das aber versuche, erhalte ich einen 403 - Forbidden-Fehler mit einer Nachricht wie dieser: example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Lösung: Ihnen fehlt eine IAM-Berechtigung für den Bucket oder das Objekt, die zum Abschließen der Anfrage erforderlich ist. Wenn Sie davon ausgehen, dass Sie die Anfrage stellen können, aber dies nicht können, führen Sie die folgenden Prüfungen durch:

1. Ist der in der Fehlermeldung genannte Empfänger derjenige, den Sie erwartet haben? Wenn die Fehlermeldung auf eine unerwartete E-Mail-Adresse oder einen „anonymen Aufrufer“ verweist, verwendet Ihre Anfrage nicht die gewünschten Anmeldedaten. Das kann daran liegen, dass das Tool, mit dem Sie die Anfrage stellen, mit den Anmeldedaten eines anderen Alias oder einer anderen Entität eingerichtet wurde, oder dass die Anfrage in Ihrem Namen von einem Dienstkonto gestellt wird.

2. Ist die in der Fehlermeldung referenzierte Berechtigung eine, die Sie benötigen? Wenn die Berechtigung unerwartet ist, liegt dies wahrscheinlich daran, dass das von Ihnen verwendete Tool zusätzlichen Zugriff benötigt, um Ihre Anfrage abzuschließen. Wenn beispielsweise Objekte in einem Bucket im Bulk gelöscht werden sollen, muss gcloud zuerst eine Liste der Objekte im Bucket erstellen, die gelöscht werden sollen. Für diesen Teil der Bulk-Löschaktion ist die Berechtigung storage.objects.list erforderlich, die möglicherweise überraschend ist, da das Ziel das Löschen von Objekten ist, für das normalerweise nur die Berechtigung storage.objects.delete erforderlich ist. Wenn dies die Ursache Ihrer Fehlermeldung ist, prüfen Sie, ob Ihnen IAM-Rollen mit den zusätzlichen erforderlichen Berechtigungen zugewiesen sind.

3. Haben Sie die IAM-Rolle für die vorgesehene Ressource oder die übergeordnete Ressource? Wenn Ihnen zum Beispiel die Rolle Storage Object Viewer für ein Projekt zugewiesen ist und Sie versuchen, ein Objekt herunterzuladen, prüfen Sie, ob sich das Objekt in einem Bucket im Projekt befindet. Möglicherweise haben Sie versehentlich die Berechtigung Storage Object Viewer für ein anderes Projekt.

4. Wird Ihre Berechtigung für den Zugriff auf einen bestimmten Bucket oder ein bestimmtes Objekt über einen Convenience-Wert erteilt? Wenn der Zugriff auf einen Convenience-Wert entfernt wird, können zuvor aktivierte Hauptkonten den Zugriff auf Ressourcen verlieren.

   Beispiel: jane@example.com hat die einfache Rolle Inhaber (roles/owner) für ein Projekt mit dem Namen my-example-project und die IAM-Richtlinie des Projekts weist den Storage-Objekt-Ersteller (roles/storage.objectCreator) dem Konvergenzwert projectOwner:my-example-project zu. Das bedeutet, dass jane@example.com die Berechtigungen hat, die mit der Rolle „Storage-Objekt-Ersteller“ für Buckets in my-example-project verknüpft sind. Wenn diese Zuweisung entfernt wird, verliert jane@example.com die mit der Rolle „Storage Object Creator“ verknüpften Berechtigungen.

   In einem solchen Fall können Sie den Zugriff auf den Bucket oder das Objekt wiederherstellen, indem Sie sich selbst die erforderlichen Berechtigungen auf Bucket- oder Objektebene gewähren, die für die gewünschten Aktionen erforderlich sind.

5. Gibt es eine IAM-Ablehnungsrichtlinie, die Sie daran hindert, bestimmte Berechtigungen zu verwenden? Wenden Sie sich an den Administrator Ihrer Organisation, um herauszufinden, ob eine IAM-Ablehnungsrichtlinie eingerichtet wurde.

403: Berechtigung verweigert

Problem: Fehler „Berechtigung verweigert“ beim Konfigurieren oder Verwalten der Storage Intelligence-Konfiguration für eine Ressource.

Lösung: Wenn Sie einen Fehler vom Typ „Berechtigung verweigert“ mit einer Meldung wie permission storage.intelligenceConfigs.update erhalten, wenn Sie Storage Intelligence für eine Ressource konfigurieren und verwalten, lesen Sie den Berechtigungsabschnitt für den Vorgang, den Sie ausführen möchten. Gewähren Sie die entsprechenden Berechtigungen, um das Problem zu beheben. Sie können Berechtigungen auf eine beliebige der folgenden Arten erteilen:

• Gewähren Sie IAM-Berechtigungen für dieselbe Ressource in der Google Cloud Ressourcenhierarchie, für die Sie Storage Intelligence aktivieren.
• Achten Sie darauf, dass eine Ressource, die in der Google Cloud Ressourcenhierarchie höher angesiedelt ist, die Berechtigungen an die untergeordnete Ressource weitergibt.

409: Konflikt

Problem: Ich habe versucht, einen Bucket zu erstellen, erhalte jedoch folgenden Fehler:

409 Conflict. Sorry, that name is not available. Please try a different one.

Lösung: Der Bucket-Name, den Sie verwenden wollten (z. B. gs://cats oder gs://dogs), ist bereits vergeben. Cloud Storage verfügt über einen globalen Namespace. Sie können einem Bucket daher keinen Namen geben, der bereits für einen anderen Bucket verwendet wird. Wählen Sie einen Namen, der noch nicht vergeben ist.

412: Benutzerdefinierte Einschränkungen verletzt

Problem: Meine Anfragen werden mit dem Fehler 412 orgpolicy abgelehnt.

Problem: Meine Anfragen werden mit dem Fehler 412 Multiple constraints were violated abgelehnt.

Lösung: Fragen Sie Ihr Sicherheitsteam, ob der Bucket, an den Sie Anfragen senden, von einer Organisationsrichtlinie mit einer benutzerdefinierten Einschränkung betroffen ist. Möglicherweise unterliegt Ihr Bucket auch verschiedenen Organisationsrichtlinien, die miteinander in Konflikt stehen. Beispiel: Eine Richtlinie gibt an, dass Buckets die Storage-Klasse „Standard“ haben müssen, und eine andere Richtlinie gibt an, dass Buckets die Storage-Klasse „Coldline“ haben müssen.

429: Zu viele Anfragen

Problem: Meine Anfragen werden mit dem Fehler 429 Too Many Requests abgelehnt.

Lösung: Sie erreichen ein Limit für die Anzahl der Anfragen, die Cloud Storage für eine bestimmte Ressource zulässt. Eine Erläuterung der Limits in Cloud Storage finden Sie unter Cloud Storage-Kontingente.

• Wenn Ihre Arbeitslast aus 1.000 Anfragen pro Sekunde an einen Bucket besteht, beachten Sie in den Richtlinien für die Anforderungsrate und Zugriffsverteilung die Best Practices, einschließlich der schrittweisen Erhöhung Ihrer Arbeitslast und der Vermeidung sequenzieller Dateinamen.

• Wenn Ihre Arbeitslast potenziell 50 Gbit/s oder mehr ausgehenden Netzwerktraffic zu bestimmten Standorten verwendet, prüfen Sie die Bandbreitennutzung, um sicherzustellen, dass Sie kein Bandbreitenkontingent erreichen.

Konsolenfehler Google Cloud diagnostizieren

Problem: Wenn ich die Google Cloud Console für einen Vorgang verwende, wird eine generische Fehlermeldung angezeigt. Ich erhalte beispielsweise eine Fehlermeldung, wenn ich versuche, einen Bucket zu löschen, es wird aber nicht angezeigt, warum der Vorgang fehlgeschlagen ist.

Lösung: Verwenden Sie die Benachrichtigungen der Google Cloud Console, um detaillierte Informationen zum fehlgeschlagenen Vorgang anzeigen zu lassen:

1. Klicken Sie im Header der Google Cloud -Konsole auf die Schaltfläche Benachrichtigungen (notifications).

   In einem Drop-down-Menü werden die zuletzt von derGoogle Cloud -Konsole ausgeführten Vorgänge angezeigt.

2. Klicken Sie auf das Element, zu dem Sie mehr erfahren möchten.

   Eine Seite mit detaillierten Informationen zum Vorgang wird geöffnet.

3. Klicken Sie auf die einzelnen Zeilen, um die detaillierten Fehlerinformationen zu maximieren.

Problem: In der Google Cloud -Konsole wird eine bestimmte Spalte nicht angezeigt.

Lösung: Wenn Sie eine bestimmte Spalte in der Google Cloud -Konsole sehen möchten, klicken Sie auf das Symbol Spaltenanzeigeoptionen (view_column) und wählen Sie die gewünschte Spalte aus.

Simulierte Ordner und verwaltete Ordner

Problem: Ich habe einige Objekte in meinem Bucket gelöscht und der Ordner, in dem sie enthalten waren, wird jetzt nicht in der Google Cloud -Konsole angezeigt.

Lösung: In der Google Cloud Console wird der Inhalt des Buckets so angezeigt, als wäre eine Verzeichnisstruktur vorhanden. Ordner existieren im Grunde nicht in Cloud Storage. Wenn Sie also alle Objekte mit einem gemeinsamen Präfix aus einem Bucket entfernen, wird das Ordnersymbol, das diese Objektgruppe darstellt, nicht mehr in der Google Cloud Console angezeigt.

Problem: Ich kann keine verwalteten Ordner erstellen.

Lösung: Achten Sie darauf, dass die folgenden Anforderungen erfüllt sind, um verwaltete Ordner zu erstellen:

• Sie haben eine IAM-Rolle mit der Berechtigung storage.managedfolders.create, z. B. die Rolle Storage-Objekt-Administrator (roles/storage.objectAdmin). Eine Anleitung zum Zuweisen von Rollen finden Sie unter IAM-Berechtigungen verwenden.

• Der einheitliche Zugriff auf Bucket-Ebene ist für den Bucket aktiviert, in dem Sie verwaltete Ordner erstellen möchten.

• Es gibt keine IAM-Bedingungen für den Bucket oder das Projekt, die den Bucket-Ressourcentyp (storage.googleapis.com/Bucket) oder den Objektressourcentyp (storage.googleapis.com/Object) verwenden. Wenn ein Bucket innerhalb eines Projekts eine IAM-Bedingung hat, die einen dieser Ressourcentypen verwendet, können verwaltete Ordner in keinem der Buckets innerhalb dieses Projekts erstellt werden, auch wenn die Bedingung später entfernt wird.

Problem: Ich kann den einheitlichen Zugriff auf Bucket-Ebene nicht deaktivieren, da in meinem Bucket verwaltete Ordner vorhanden sind.

Lösung: Der einheitliche Zugriff auf Bucket-Ebene kann nicht deaktiviert werden, wenn der Bucket verwaltete Ordner enthält. Wenn Sie den einheitlichen Zugriff auf Bucket-Ebene deaktivieren möchten, müssen Sie zuerst alle verwalteten Ordner im Bucket löschen.

Fehler bei einer statischen Website

Die folgenden Probleme treten häufig auf, wenn Sie einen Bucket zum Hosten einer statischen Website einrichten.

HTTPS-Bereitstellung

Problem: Ich möchte meine Inhalte über HTTPS bereitstellen, ohne einen Load-Balancer zu verwenden.

Lösung: Sie können statische Inhalte über HTTPS mit direkten URIs wie https://storage.googleapis.com/my-bucket/my-object bereitstellen. Außerdem haben Sie zur Bereitstellung Ihrer Inhalte über eine benutzerdefinierte Domain und SSL folgende Möglichkeiten:

• Ein Content Delivery Network eines Drittanbieters mit Cloud Storage verwenden.
• Inhalte Ihrer statischen Website mit Firebase Hosting statt mit Cloud Storage bereitstellen.

Seite nicht zugänglich

Problem: Ich erhalte die Fehlermeldung Access denied für eine Webseite, die über meine Website bereitgestellt wird.

Lösung: Prüfen Sie, ob das Objekt öffentlich freigegeben ist. Wenn dies nicht der Fall ist, finden Sie eine Anleitung dazu unter Daten öffentlich machen.

Wenn Sie zuvor ein Objekt hochgeladen und freigegeben haben und dann eine neue Version hochladen, müssen Sie das Objekt noch einmal öffentlich freigeben. Der Grund hierfür ist, dass die öffentliche Berechtigung mit dem neuen Upload ersetzt wird.

Herunterladen von Inhalten

Problem: Meine Website wird im Browser nicht dargestellt. Stattdessen werde ich aufgefordert, den Inhalt meiner Website herunterzuladen.

Lösung: Wenn Sie ein MainPageSuffix als Objekt angeben, das keinen Webinhaltstyp aufweist, werden die Besucher der Website aufgefordert, den Inhalt herunterzuladen, anstatt die ausgelieferten Seiteninhalte zu sehen. Aktualisieren Sie den Metadateneintrag Content-Type auf einen geeigneten Wert wie text/html, um dieses Problem zu beheben. Eine Anleitung finden Sie unter Objektmetadaten bearbeiten.

Daten öffentlich bereitstellen

Problem: Ich versuche, meine Daten zu veröffentlichen, erhalte aber eine Fehlermeldung zu einer Organisationsrichtlinie.

Lösung: Einige Einschränkungen von Organisationsrichtlinien können verhindern, dass Sie Ihre Daten öffentlich machen. Die Einschränkung „Domaineingeschränkte Freigabe“ (constraints/iam.allowedPolicyMemberDomains) beschränkt beispielsweise die Ressourcenfreigabe auf Grundlage der Domain der Organisation. Wenden Sie sich bei Verstößen gegen Organisationsrichtlinien an Ihren Administrator, damit er Ihnen die Berechtigungen auf Projekt- oder Bucket-Ebene gewährt, die für die Freigabe von Ressourcen erforderlich sind. Bearbeiten Sie dazu die Organisationsrichtlinie für die Organisations-, Ordner- oder Projektressource. Wenn dieser Fehler nach dem Überschreiben der Organisationsrichtlinie weiterhin angezeigt wird, müssen Sie möglicherweise einige Minuten warten, bis die Änderung wirksam wird.

Problem: Ich erhalte eine Berechtigungsfehlermeldung, wenn ich versuche, meine Daten zu veröffentlichen.

Lösung: Prüfen Sie, ob Sie die Berechtigung storage.buckets.setIamPolicy oder die Berechtigung storage.objects.setIamPolicy haben. Diese Berechtigungen sind beispielsweise in der Rolle „Storage-Administrator“ (roles/storage.admin) enthalten. Wenn Sie die Berechtigung storage.buckets.setIamPolicy oder storage.objects.setIamPolicy haben und weiterhin einen Fehler erhalten, unterliegt Ihr Bucket möglicherweise der Verhinderung des öffentlichen Zugriffs, wodurch der Zugriff auf allUsers oder allAuthenticatedUsers nicht möglich ist. Die Verhinderung des öffentlichen Zugriffs kann direkt für den Bucket festgelegt oder über eine Organisationsrichtlinie erzwungen werden, die auf einer höheren Ebene festgelegt ist.

Latenz

Nachfolgend einige Beispiele für häufig auftretende Latenzprobleme. Das Google Cloud Service Health-Dashboard enthält Informationen zu Vorfällen, die Google Cloud -Dienste wie Cloud Storage betreffen.

Latenz beim Hochladen oder Herunterladen

Problem: Beim Hochladen oder Herunterladen tritt eine erhöhte Latenz auf.

Lösung: Beachten Sie die folgenden häufigen Ursachen für Latenz beim Hochladen oder Herunterladen:

• CPU- oder Speichereinschränkungen: Das Betriebssystem der betroffenen Umgebung sollte Tools zur Messung des lokalen Ressourcenverbrauchs haben, z. B. zur CPU- und Arbeitsspeichernutzung.

• Laufwerk-E/A-Beschränkungen: Die Leistungseinbußen können durch lokale Laufwerk-E/A verursacht werden.

• Geografische Entfernung: Die Leistung kann durch die physische Trennung Ihres Cloud Storage-Buckets und der betroffenen Umgebung beeinflusst werden, insbesondere in Interkontinentalen Szenarien. Tests mit einem Bucket, der sich in derselben Region wie die betroffene Umgebung befindet, können zeigen, inwieweit die geografische Trennung zu Ihrer Latenz beiträgt.

  • Gegebenenfalls sollte der DNS-Resolver der betroffenen Umgebung das EDNS(0)-Protokoll verwenden, damit Anfragen aus der Umgebung über ein entsprechendes Google Front End weitergeleitet werden.

Latenz der Befehlszeile oder der Clientbibliothek

Problem: Beim Zugriff auf Cloud Storage mit der Google Cloud CLI oder einer der Clientbibliotheken tritt eine erhöhte Latenz auf.

Lösung: Sowohl gcloud CLI als auch Clientbibliotheken wiederholen Anfragen automatisch, wenn dies sinnvoll ist. Dieses Verhalten kann die Latenz aus Sicht des Endnutzers erhöhen. Verwenden Sie den Cloud Monitoring-Messwert storage.googleapis.com/api/request_count, um festzustellen, ob Cloud Storage konsistent einen wiederholbaren Antwortcode wie 429 oder 5xx bereitstellt.

Proxyserver

Problem: Ich stelle die Verbindung über einen Proxyserver her. Was muss ich tun?

Lösung: Für den Zugriff auf Cloud Storage über einen Proxyserver müssen Sie den Zugriff auf diese Domains zulassen:

• accounts.google.com zum Erstellen von OAuth2-Authentifizierungstokens
• oauth2.googleapis.com für den OAuth2-Token-Austausch
• *.googleapis.com für Speicheranfragen

Wenn Ihr Proxyserver oder Ihre Sicherheitsrichtlinie die Zulassungsliste nach Domain nicht unterstützt und stattdessen nur Zulassungslisten nach IP-Netzwerkblock unterstützt, empfehlen wir dringend, Ihren Proxyserver für alle IP-Adressbereiche von Google zu konfigurieren. Diese Adressbereiche finden Sie durch Abfrage der WHOIS-Daten unter ARIN. Als Best Practice sollten Sie Ihre Proxy-Einstellungen regelmäßig prüfen, um dafür zu sorgen, dass sie mit den IP-Adressen von Google übereinstimmen.

Wir raten davon ab, den Proxy mit einzelnen IP-Adressen zu konfigurieren, die Sie durch einmalige Suchvorgänge von oauth2.googleapis.com und storage.googleapis.com erhalten. Google-Dienste werden über DNS-Namen bereitgestellt, denen viele IP-Adressen zugeordnet sind, die sich im Laufe der Zeit ändern können. Daher können bei der Verbindung mit Cloud Storage Fehler auftreten, wenn Sie den Proxy auf der Grundlage einer einzelnen Abfrage konfigurieren.

Wenn Ihre Anfragen über einen Proxyserver geleitet werden, klären Sie mit Ihrem Netzwerkadministrator, dass der Authorization-Header mit Ihren Anmeldedaten nicht durch den Proxy entfernt werden darf. Ohne den Authorization-Header werden Ihre Anfragen abgelehnt und Sie erhalten den Fehler MissingSecurityHeader.

Storage Insights-Fehler

Problem: Meine Konfiguration für den Inventarbericht generiert täglich mehrere Inventarberichte.

Lösung: Wenn sich in Ihrem Bucket mehr als 1.000.000 Objekte befinden, können mehrere Inventarberichte als Shards generiert werden. Eine Inventarberichtskonfiguration generiert einen Inventarbericht pro 1.000.000 Objekte im Bucket. Beispiel: Wenn Sie einen Bucket mit 3.500.000 Objekten haben, generiert die Inventarberichtskonfiguration für den Bucket vier Inventarberichts-Shards gemäß der von Ihnen angegebenen Häufigkeit sowie eine Manifestdatei, die die Anzahl der generierten Inventarbericht-Shards und deren Dateinamen enthält.

Problem: Inventarberichte werden im Ziel-Bucket nicht angezeigt.

Lösung: Wenn Sie eine Inventarberichtskonfiguration erstellt haben und keine Inventarberichte im Ziel-Bucket generiert werden, prüfen Sie Folgendes:

• Achten Sie darauf, dass das in der Konfiguration des Inventarberichts angegebene Startdatum Ihren Erwartungen entspricht, wann Inventarberichte generiert werden sollen. Eine Anleitung zum Angeben eines Startdatums finden Sie unter Inventarberichtskonfiguration erstellen.

• Prüfen Sie den Verlauf der Inventarberichte, um nach Fehlern und deren Ursachen zu suchen. Führen Sie die folgenden Schritte aus, um den Verlauf Ihrer Inventarberichte aufzurufen:

  1. Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.
     

     Buckets aufrufen

  2. Klicken Sie in der Liste der Buckets auf den Namen des Quell-Buckets, der die Inventarberichtskonfiguration enthält.

  3. Klicken Sie auf der Seite Bucket-Details auf den Tab Inventarberichte.

  4. Klicken Sie in der Liste der Inventarberichtskonfigurationen auf die UUID der Inventarberichtskonfiguration, über die die Berichte generiert wurden, die Sie prüfen möchten.

  5. Sehen Sie im Bereich Verlauf der Inventarberichte nach, ob Fehler vorliegen. Sie können den Mauszeiger über Hilfe (help) halten, um Details darüber zu erhalten, warum ein Fehler aufgetreten ist.

• Prüfen Sie, ob dem Dienst-Agent auf Projektebene die IAM-Rollen zugewiesen sind, die zum Lesen und Schreiben von Inventarberichten erforderlich sind. Eine Anleitung finden Sie unter Erforderliche Rollen für den Dienst-Agent zuweisen.

Problem: Bei der Erstellung von Inventarberichten treten zufällige Verzögerungen auf.

Lösung: Das Zeitintervall zwischen der Generierung von Inventarberichten kann variieren. Dabei kann es zu einer Verzögerung von bis zu einem Tag kommen.

Nächste Schritte

• Antworten auf weitere Fragen sind in den FAQ zu Cloud Storage enthalten.
• Informationen zu Supportoptionen
• Erfahren Sie, wie Sie mithilfe von Error Reporting Cloud Storage-Fehler identifizieren und verstehen können.