このページでは、Cloud Storage の使用中に発生する可能性のある一般的なエラーをトラブルシューティングする方法について説明します。
Cloud Storage などの Google Cloud サービスに影響するインシデントについては、Google Cloud Service Health ダッシュボードをご覧ください。
未加工リクエストのロギング
gcloud
や Cloud Storage クライアント ライブラリなどのツールを使用する場合、リクエストとレスポンスの情報の多くはツールで処理されます。ただし、トラブルシューティングや、Stack Overflow などのフォーラムに質問を投稿する際に役立つ情報があると便利な場合があります。ツールのリクエスト ヘッダーとレスポンス ヘッダーを返すには、次の手順を使用します。
コンソール
リクエストとレスポンスの情報を表示する方法は、Google Cloud コンソールへのアクセスに使用しているブラウザによって異なります。Google Chrome ブラウザの場合:
Chrome のメインメニュー ボタン(more_vert)をクリックします。
[その他のツール] を選択します。
[デベロッパー ツール] をクリックします。
表示されたペインで [Network] タブをクリックします。
コマンドライン
リクエストでグローバル デバッグフラグを使用します。次に例を示します。
gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug
クライアント ライブラリ
C++
HTTP トラフィック全体を取得するには、環境変数
CLOUD_STORAGE_ENABLE_TRACING=http
を設定します。RPC ごとにログを取得するには、環境変数 CLOUD_STORAGE_ENABLE_CLOG=yes を設定します。
C#
ApplicationContext.RegisterLogger
を使用してロガーを追加し、HttpClient
メッセージ ハンドラでロギング オプションを設定します。詳細については、よくある質問をご覧ください。
Go
環境変数 GODEBUG=http2debug=1
を設定します。詳しくは、Go パッケージ net/http をご覧ください。
リクエスト本文もロギングする場合は、カスタム HTTP クライアントを使用します。
Java
次の内容のファイルを「logging.properties」という名前で作成します。
# Properties file which configures the operation of the JDK logging facility. # The system will look for this config file to be specified as a system property: # -Djava.util.logging.config.file=${project_loc:googleplus-simple-cmdline-sample}/logging.properties # Set up the console handler (uncomment "level" to show more fine-grained messages) handlers = java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.level = CONFIG # Set up logging of HTTP requests and responses (uncomment "level" to show) com.google.api.client.http.level = CONFIG
Maven で logging.properties を使用します。
mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command
詳細については、プラガブル HTTP トランスポートをご覧ください。
Node.js
Node スクリプトを呼び出す前に、環境変数 NODE_DEBUG=https
を設定します。
PHP
httpHandler
を使用して独自の HTTP ハンドラをクライアントに提供し、リクエストとレスポンスをロギングするためのミドルウェアを設定します。
Python
ロギング モジュールを使用します。次に例を示します。
import logging import http.client logging.basicConfig(level=logging.DEBUG) http.client.HTTPConnection.debuglevel=5
Ruby
.rb file
の先頭、require "google/cloud/storage"
の後に以下を追加します。
ruby Google::Apis.logger.level = Logger::DEBUG
カスタム ヘッダーの追加
カスタム ヘッダーをリクエストに追加することは、デバッグ ヘッダーの有効化やリクエストのトレースなど、デバッグを目的とした一般的な方法です。次の例は、さまざまな Cloud Storage ツールでリクエスト ヘッダーを設定する方法を示しています。
コマンドライン
--additional-headers
フラグを使用します。このフラグはほとんどのコマンドで使用できます。次に例を示します。
gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE
ここで、HEADER_NAME
と HEADER_VALUE
はリクエストに追加するヘッダーを定義します。
クライアント ライブラリ
C++
namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));
C#
次のサンプルでは、クライアント ライブラリから送信されるすべてのリクエストにカスタム ヘッダーを追加します。
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);
}
Go
Go クライアント ライブラリから送信されるリクエストにカスタム ヘッダーを追加するには、クライアントで使用されるトランスポートをカスタムの RoundTripper
でラップする必要があります。次の例では、デバッグ ヘッダーを送信し、対応するレスポンス ヘッダーをログに記録します。
package main
import (
"context"
"io/ioutil"
"log"
"net/http"
"cloud.google.com/go/storage"
"google.golang.org/api/option"
raw "google.golang.org/api/storage/v1"
htransport "google.golang.org/api/transport/http"
)
func main() {
ctx := context.Background()
// Standard way to initialize client:
// client, err := storage.NewClient(ctx)
// if err != nil {
// // handle error
// }
// Instead, create a custom http.Client.
base := http.DefaultTransport
trans, err := htransport.NewTransport(ctx, base, option.WithScopes(raw.DevstorageFullControlScope),
option.WithUserAgent("custom-user-agent"))
if err != nil {
// Handle error.
}
c := http.Client{Transport:trans}
// Add RoundTripper to the created HTTP client.
c.Transport = withDebugHeader{c.Transport}
// Supply this client to storage.NewClient
client, err := storage.NewClient(ctx, option.WithHTTPClient(&c))
if err != nil {
// Handle error.
}
// Use client to make a request
}
type withDebugHeader struct {
rt http.RoundTripper
}
func (wdh withDebugHeader) RoundTrip(r *http.Request) (*http.Response, error) {
headerName := "X-Custom-Header"
r.Header.Add(headerName, "value")
resp, err := wdh.rt.RoundTrip(r)
if err == nil {
log.Printf("Resp Header: %+v, ", resp.Header.Get(headerName))
} else {
log.Printf("Error: %+v", err)
}
return resp, err
}
Java
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));
}
}
}
Node.js
const storage = new Storage();
storage.interceptors.push({
request: requestConfig => {
Object.assign(requestConfig.headers, {
'X-Custom-Header': 'value',
});
return requestConfig;
},
});
PHP
HTTP リクエストをトリガーするすべてのメソッド呼び出しでは、最後の引数としてオプションの $restOptions
引数を受け取ることができます。カスタム ヘッダーは、リクエストごとまたはクライアントごとに指定できます。
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'
]
]
]);
Python
from google.cloud import storage
client = storage.Client(
extra_headers={
"x-custom-header": "value"
}
)
Ruby
require "google/cloud/storage"
storage = Google::Cloud::Storage.new
storage.add_custom_headers { 'X-Custom-Header'=> 'value' }
CORS 構成によるバケットへのアクセス
バケットに CORS 構成を設定していて、クライアント ブラウザからの受信リクエストが失敗する場合は、次のトラブルシューティングの手順を試します。
ターゲット バケットの CORS 構成を確認します。複数の CORS 構成エントリがある場合は、トラブルシューティングに使用するリクエスト値が、1 つの CORS 構成エントリにある値にマッピングされていることを確認します。
CORS リクエストの発行をテストする際は、CORS リクエストが許可されていない
storage.cloud.google.com
エンドポイントにリクエストを発行していないことを確認します。CORS でサポートされているエンドポイントの詳細については、Cloud Storage CORS のサポートをご覧ください。任意のツールを使用して、リクエストとレスポンスをレビューします。Chrome ブラウザでは、標準のデベロッパー ツールを使用してこの情報を確認できます。
- ブラウザのツールバーで Chrome メニュー(more_vert)をクリックします。
- [その他のツール] > [デベロッパー ツール] の順に選択します。
- [Network] タブをクリックします。
- アプリケーションまたはコマンドラインから、リクエストを送信します。
- ネットワーク アクティビティが表示されているペインで、リクエストを探します。
- [Name] 列で、リクエストに対応する名前をクリックします。
- [Headers] タブをクリックしてレスポンス ヘッダーを確認するか、[Response] タブをクリックしてレスポンスの内容を表示します。
リクエストとレスポンスが表示されない場合は、以前の失敗したプリフライト リクエストがブラウザのキャッシュに残っている可能性があります。ブラウザのキャッシュをクリアすると、プリフライトのキャッシュもクリアされます。クリアされない場合は、CORS 構成の
MaxAgeSec
値をデフォルト値の1800
(30 分)よりも小さい値に設定し、変更前のMaxAgeSec
に設定されていた時間よりも長い時間待機したうえで、再度リクエストを試します。これにより新しいプリフライト リクエストが実行されて、新しい CORS 構成が取得され、キャッシュ エントリが削除されます。問題をデバッグし終えたら、MaxAgeSec
を元の大きい値に戻して、バケットへのプリフライトのトラフィックを削減します。リクエストに
Origin
ヘッダーがあること、およびヘッダー値がバケットの CORS 構成内のOrigins
値の少なくとも 1 つと一致することを確認します。値のスキーム、ホスト、およびポートが正確に一致している必要があります。適切な一致の例を次に示します。http://origin.example.com
はhttp://origin.example.com:80
と一致しています(80 がデフォルトの HTTP ポートであるため)が、https://origin.example.com
、http://origin.example.com:8080
、http://origin.example.com:5151
、http://sub.origin.example.com
とは一致していません。https://example.com:443
はhttps://example.com
と一致しますが、http://example.com
、http://example.com:443
とは一致しません。http://localhost:8080
はhttp://localhost:8080
のみと正確に一致していて、http://localhost:5555
やhttp://localhost.example.com:8080
とは一致していません。
簡潔なリクエストの場合、その HTTP メソッドが、バケットの CORS 構成にある
Methods
値の少なくとも 1 つと一致していることを確認します。プリフライト リクエストの場合、Access-Control-Request-Method
で指定したメソッドがMethods
値の少なくとも 1 つと一致していることを確認します。プリフライト リクエストの場合は、
Access-Control-Request-Header
ヘッダーがあるかどうかを確認します。そのヘッダーがある場合は、各Access-Control-Request-Header
値がバケットの CORS 構成にあるResponseHeader
値と一致することを確認します。プリフライト リクエストが正常に終了し、レスポンスに CORS ヘッダーが含まれるためには、Access-Control-Request-Header
に指定したすべてのヘッダーが CORS 構成に含まれていることが必要です。
エラーコード
発生する可能性のある一般的な HTTP ステータス コードは次のとおりです。
301: Moved Permanently
問題: 静的ウェブサイトの設定中に、ディレクトリ パスにアクセスすると空のオブジェクトと 301
HTTP レスポンス コードが返されます。
解決策: http://www.example.com/dir/
などのディレクトリにアクセスしたときに、ブラウザがゼロバイトのオブジェクトをダウンロードして、301
HTTP レスポンス コードが表示された場合、バケットにはその名前の空のオブジェクトが含まれている可能性が非常に高くなります。これを確認して問題を解決するには、次のようにします。
- Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
- Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」ボタンをクリックします。
gcloud storage ls --recursive gs://www.example.com/dir/
を実行します。出力にhttp://www.example.com/dir/
が含まれている場合は、その場所に空のオブジェクトがあります。- コマンド
gcloud storage rm gs://www.example.com/dir/
で空のオブジェクトを削除します。
これで、http://www.example.com/dir/
にアクセスして、空のオブジェクトの代わりにそのディレクトリの index.html
ファイルを返すことができます。
400: Bad Request
問題: 再開可能なアップロードの実行中に、次のエラーとメッセージを受信しました: Failed to parse Content-Range header.
解決策: Content-Range
ヘッダーで使用した値が無効です。たとえば、Content-Range: */*
は無効で、Content-Range: bytes */*
として指定する必要があります。このエラーが表示された場合は、現在の再開可能アップロードがアクティブでなくなったため、新しい再開可能なアップロードを開始する必要があります。
401: Unauthorized
問題: 一般公開のバケットに直接、または Cloud CDN 経由でリクエストすると、HTTP 401: Unauthorized
と Authentication Required
のレスポンスで失敗します。
解決策: クライアントまたは中間プロキシによって、Cloud Storage へのリクエストに Authorization
ヘッダーが追加されていないことを確認します。Authorization
ヘッダーを含むリクエストは、空の場合でも、認証試行であるかのように検証されます。
403: Account Disabled
問題: バケットを作成しようとしましたが、403 Account Disabled
エラーが発生しました。
解決策: このエラーは、関連付けられているプロジェクトの課金がまだ有効になっていないことを示しています。課金を有効にする手順については、プロジェクトの課金を有効にするをご覧ください。
課金が有効になっているにもかかわらず、このエラー メッセージが引き続き表示される場合は、サポートに連絡してプロジェクト ID と問題の状況をお伝えください。
403: Forbidden
問題: 特定のバケットまたはオブジェクトにアクセスするための権限が付与されているはずですが、アクセスを試みると 403 - Forbidden
エラーが発生し、「example@email.com does not have storage.objects.get access to the
Google Cloud Storage object
」のようなメッセージが表示されます。
解決策: バケットまたはオブジェクトに対して、リクエストの完了に必要な IAM 権限がありません。リクエストを行うことができない場合は、次のことを確認してください。
権限の付与先としてエラー メッセージに示されているメールアドレスが想定されたものかどうか。エラー メッセージに予期しないメールアドレスが表示されている場合や、「匿名の呼び出し側」が表示されている場合は、意図した認証情報がリクエストで使用されていません。リクエストに使用しているツールが、別のエイリアスまたはエンティティの認証情報で設定されている可能性があります。また、リクエストがユーザーの代わりにサービス アカウントによって行われている可能性があります。
エラー メッセージに示された権限が、必要であると想定していたものかどうか。想定外の権限が示されている場合は、使用しているツールがリクエストを完了するために別のアクセス権を必要としている可能性があります。たとえば、バケット内のオブジェクトを一括削除するには、まず
gcloud
を使用して、削除するバケット内のオブジェクトのリストを作成する必要があります。一括削除のこの部分ではstorage.objects.list
権限が必要ですが、オブジェクトの削除では通常、storage.objects.delete
権限のみが必要になるため、この追加の権限は想定されていないかもしれません。これがエラー メッセージの原因である場合は、追加で必要な権限を含む IAM ロールを付与します。目的のリソースまたは親リソースの IAM ロールが付与されているか。たとえば、プロジェクトの
Storage Object Viewer
ロールがあなたに付与されていて、オブジェクトのダウンロードを試みている場合は、そのプロジェクトのバケット内に対象のオブジェクトがあることを確認してください。別のプロジェクトのStorage Object Viewer
権限が誤って付与されている可能性があります。特定のバケットまたはオブジェクトへのアクセス権限が、コンビニエンス値を通じて付与されたものであるか。コンビニエンス値に付与されたアクセス権を削除すると、以前にリソースにアクセス可能であったプリンシパルが、リソースにアクセスできなくなることがあります。
たとえば、jane@example.com はプロジェクト
my-example-project
に対するオーナー(roles/owner
)基本ロールを持っているとします。また、プロジェクトの IAM ポリシーによって、コンビニエンス値projectOwner:my-example-project
に Storage オブジェクト作成者(roles/storage.objectCreator
)ロールが付与されているとします。この場合、jane@example.com には、my-example-project
内のバケットに対する Storage オブジェクト作成者のロールに関連付けられた権限を持っていることになります。この付与が削除されると、jane@example.com は Storage オブジェクト作成者ロールに関連付けられた権限を失います。このような場合は、目的の操作を実行するために必要なバケットレベルまたはオブジェクト レベルの権限を自身に付与することで、バケットまたはオブジェクトへのアクセス権を回復できます。
特定の権限の使用を禁止する IAM 拒否ポリシーがあるか。IAM 拒否ポリシーが設定されているかどうかを確認するには、組織管理者にお問い合わせください。
403: Forbidden
問題: storage.cloud.google.com
からコンテンツをダウンロードしているときに、ブラウザで URL を使用してオブジェクトに移動すると、403: Forbidden
エラーが発生します。
https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME
解決策: storage.cloud.google.com
を使用してオブジェクトをダウンロードする方法は、認証済みブラウザでのダウンロードといいます。この方法では、Cookie ベースの認証が行われます。オブジェクトへのアクセスを追跡するように、Cloud Audit Logs のデータアクセス監査ログを構成している場合、この機能の制限により、追跡されたオブジェクトを認証済みブラウザでダウンロードできません。ただし、次のいずれかが適用される場合は、この限りではありません。
- オブジェクトが公開読み取り可能である
- オブジェクトが Google Cloud コンソールからアクセスされている
認証済みブラウザで別途ダウンロードしようとすると、403
レスポンスが返されます。この制限は、Cookie ベースの認証に使用される Google ID のフィッシングを防ぐために存在します。
この問題を回避するには、以下のいずれかを行います。
- 認証済みブラウザでのダウンロードではなく、未認証のダウンロードをサポートする直接 API 呼び出しを使用します。
- 影響を受けるオブジェクトへのアクセスを追跡する Cloud Storage のデータアクセス監査ログを無効にします。データアクセス監査ログはプロジェクト レベル以上で設定されます。また、複数のレベルで同時に有効にすることもできます。
- 除外を設定すると、データアクセス監査ログの追跡から特定のユーザーを除外できます。指定したユーザーは、認証済みブラウザでダウンロードを実行できます。
allUsers
またはallAuthenticatedUsers
のいずれかに読み取り権限を付与すると、影響を受けるオブジェクトを公開し、読み取り可能にすることができます。データアクセス監査ログには、公開オブジェクトへのアクセスは記録されません。
409: Conflict
問題: バケットを作成しようとしましたが、次のエラーが発生しました。
409 Conflict. Sorry, that name is not available. Please try a different one.
解決策: 使用しようとしたバケット名(gs://cats
や gs://dogs
など)は、すでに使用されています。Cloud Storage ではグローバルな名前空間を使用しているため、バケットに既存のバケットと同じ名前を付けることはできません。まだ使用されていない名前を選んでください。
412: Custom constraints violated
問題: リクエストが 412 orgpolicy
エラーで拒否されます。
問題: リクエストが 412 Multiple constraints were violated
エラーで拒否されます。
解決策: セキュリティ管理者チームに、リクエストの送信先となるバケットが、カスタム制約を使用する組織のポリシーの影響を受けるかどうかを確認します。バケットは、互いに競合する組織のポリシーの影響を受ける場合もあります。たとえば、あるポリシーではバケットに Standard ストレージ クラスが必要と指定され、別のポリシーではバケットには Coldline ストレージ クラスが必要と指定されています。
429: Too Many Requests
問題: リクエストが 429 Too Many Requests
エラーで拒否されます。
解決策: Cloud Storage で特定のリソースに許可されるリクエスト数の上限に達しました。Cloud Storage の上限については、Cloud Storage の割り当てをご覧ください。
ワークロードでバケットに対して毎秒 1,000 件のリクエストが発生する場合は、リクエスト レートとアクセス配信のガイドラインで、ワークロードの段階的な増加や連続したファイル名の回避などのベスト プラクティスをご確認ください。
ワークロードで特定のロケーションへの 50 Gbps 以上のネットワーク下り(外向き)が使用される可能性がある場合は、帯域幅の使用量を確認して、帯域幅の割り当ての問題が発生しないことを確認します。
Google Cloud コンソールのエラーを診断する
問題: Google Cloud コンソールを使用して操作すると、汎用のエラー メッセージが表示されます。たとえば、バケットを削除しようとするとエラー メッセージが表示されますが、操作が失敗した詳しい理由は表示されません。
解決策: Google Cloud コンソールの通知を使用して、失敗した操作に関する詳細情報を確認します。
Google Cloud コンソールのヘッダーにある通知ボタン(notifications)をクリックします。
プルダウンに、Google Cloud コンソールで最近実行されたオペレーションが表示されます。
詳細を確認したい項目をクリックします。
ページが開き、操作に関する詳細情報が表示されます。
各行をクリックして、詳細なエラー情報を開きます。
問題: Google Cloud コンソールを使用すると、特定の列が表示されません。
解決策: Google Cloud コンソールにその列を表示するには、列表示オプション アイコン(
)をクリックして、表示する列を選択します。シミュレートされたフォルダとマネージド フォルダ
問題: バケット内の一部のオブジェクトが削除され、そのオブジェクトが格納されているフォルダが Google Cloud コンソールに表示されません。
解決策: Google Cloud コンソールでは、バケットの中身がディレクトリ構造のように表示されますが、Cloud Storage にはフォルダが基本的に存在しません。そのため、共通の接頭辞を持つすべてのオブジェクトをバケットから削除すると、そのオブジェクト グループを表すフォルダ アイコンが Google Cloud コンソールに表示されなくなります。
問題: マネージド フォルダを作成できません。
解決策: マネージド フォルダを作成するには、次の要件を満たしていることを確認してください。
Storage オブジェクト管理者(
roles/storage.objectAdmin
)ロールなど、storage.managedfolders.create
権限を含む IAM ロールが付与されている。ロールの付与手順については、IAM 権限を使用するをご覧ください。均一なバケットレベルのアクセスが、マネージド フォルダを作成するバケットで有効になります。
バケットまたはプロジェクトに、バケットのリソースタイプ(
storage.googleapis.com/Bucket
)またはオブジェクトのリソースタイプ(storage.googleapis.com/Object
)を使用する IAM 条件がありません。プロジェクト内のいずれかのバケットに、これらのリソースタイプのいずれかを使用する IAM 条件が設定されている場合、後で条件が削除されても、そのプロジェクト内のどのバケットにもマネージド フォルダを作成できません。
問題: バケットにマネージド フォルダがあるため、均一なバケットレベルのアクセスを無効にできません。
解決策: バケットにマネージド フォルダがある場合、均一なバケットレベルのアクセスを無効にできません。均一なバケットレベルのアクセスを無効にするには、まずバケット内のすべてのマネージド フォルダを削除する必要があります。
静的ウェブサイトのエラー
ここでは、静的ウェブサイトをホストするバケットを設定するときに発生する可能性がある一般的な問題について説明します。
HTTPS による配信
問題: ロードバランサを使用せずに HTTPS でコンテンツを配信するにはどうしたらよいですか。
解決策: https://storage.googleapis.com/my-bucket/my-object
などの直接 URI を使用すると、HTTPS で静的コンテンツを配信できます。SSL 経由でカスタム ドメインからコンテンツを配信する別のオプションについては、次をご覧ください。
- Cloud Storage でサードパーティのコンテンツ配信ネットワークを使用します。
- Cloud Storage ではなく Firebase Hosting から静的ウェブサイトのコンテンツを配信します。
ドメインの確認
問題: ドメインを確認できません。
解決策: 通常、Search Console の確認プロセスでは、ドメインにファイルをアップロードするように指示されますが、関連するバケットを最初に作成しないと、これを行うことはできません。バケットは、ドメインの所有権の証明を行った後にしか作成できません。
この場合、ドメイン名プロバイダの確認方法を使用して所有権を確認します。これを実行する手順については、所有権の確認をご覧ください。ドメインの確認はバケットの作成前に行えます。
アクセスできないページ
問題: ウェブサイトから提供されるウェブページでエラー メッセージ Access denied
が表示されました。
解決策: オブジェクトが一般公開として共有されていることを確認します。共有されていない場合は、その方法についてデータの一般公開をご覧ください。
以前にオブジェクトをアップロードして共有するよう設定していても、新しいバージョンのオブジェクトをアップロードした場合は、オブジェクトを一般公開として共有するよう再度設定する必要があります。これは、新しいバージョンのオブジェクトをアップロードすると、一般公開権限が置換されるためです。
権限を更新できませんでした
問題: データを公開しようとしたときにエラーが表示されました。
解決策: storage.buckets.setIamPolicy
権限または storage.objects.setIamPolicy
権限があることを確認します。これらの権限は、ストレージ管理者(roles/storage.admin
)ロールなどで付与されます。storage.buckets.setIamPolicy
権限または storage.objects.setIamPolicy
権限があるにもかかわらずエラーが表示される場合は、バケットが公開アクセス防止の対象になっていることが考えられます。公開アクセスが防止されている場合は、allUsers
または allAuthenticatedUsers
にアクセスできません。公開アクセス防止は、バケットに直接設定されるか、上位レベルで設定された組織のポリシーによって適用される場合があります。
コンテンツのダウンロード
問題: ページのコンテンツがブラウザに表示されず、ダウンロードするように求められます。
解決策: ウェブ コンテンツ タイプを持たないオブジェクトとして MainPageSuffix
を指定すると、サイト訪問者は、提供されたコンテンツを見る代わりに、コンテンツをダウンロードするよう求められます。この問題を解決するには、Content-Type
メタデータ エントリを適切な値(text/html
など)に更新します。手順については、オブジェクトのメタデータを編集するをご覧ください。
レイテンシ
レイテンシについて発生する一般的な問題は次のとおりです。Google Cloud Service Health ダッシュボードで、Cloud Storage などの Google Cloud サービスに影響するインシデントを確認することもできます。
アップロードまたはダウンロードのレイテンシ
問題: アップロード時またはダウンロード時にレイテンシが増えます。
解決策: アップロードとダウンロードのレイテンシに関して、次の一般的な原因を考慮してください。
CPU またはメモリの制約: 影響を受ける環境のオペレーティング システムに、CPU 使用率やメモリ使用量などのローカル リソースの使用量を測定するツールが必要です。
ディスク I/O の制約: ローカル ディスクの I/O が原因でパフォーマンスに影響することがあります。
地理的な距離: Cloud Storage バケットと環境の物理的な距離がパフォーマンスに影響することがあります(特に大陸をまたいでいる場合など)。影響を受ける環境と同じリージョンにあるバケットでテストすることで、地理的に離れていることがレイテンシにどの程度影響するかを特定できます。
- 該当する場合は、影響を受ける環境の DNS リゾルバで EDNS(0) プロトコルを使用して、環境からのリクエストが適切な Google Front End 経由でルーティングされるようにする必要があります。
CLI またはクライアント ライブラリのレイテンシ
問題: Google Cloud CLI またはクライアント ライブラリの 1 つを使用して Cloud Storage にアクセスすると、レイテンシが増加します。
解決策: gcloud CLI とクライアント ライブラリは、必要に応じてリクエストを自動的に再試行します。この動作は、エンドユーザーから見るとレイテンシを効果的に増加させる可能性があります。Cloud Monitoring の指標 storage.googleapis.com/api/request_count
を使用して、Cloud Storage が再試行可能なレスポンス コード(429
や 5xx
など)を一貫して返しているかどうかを確認します。
プロキシ サーバー
問題: プロキシ サーバー経由で接続しています。どのような操作が必要ですか。
解決策: プロキシ サーバー経由で Cloud Storage にアクセスするには、以下のドメインへのアクセスを許可する必要があります。
accounts.google.com
: OAuth2 認証トークンを作成するためoauth2.googleapis.com
: OAuth2 トークンの交換を実行するため*.googleapis.com
: ストレージ リクエスト用
プロキシ サーバーまたはセキュリティ ポリシーがドメインによる許可リスト登録をサポートしておらず、代わりに IP ネットワーク ブロックによる許可リスト登録のみをサポートしている場合は、プロキシ サーバーを Google IP アドレスの全範囲に合わせて構成することをおすすめします。アドレスの範囲を確認するには、ARIN で WHOIS データのクエリを行います。定期的にプロキシ設定を確認し、Google の IP アドレスと一致させることをおすすめします。
oauth2.googleapis.com
と storage.googleapis.com
を一度だけ検索して取得した個別の IP アドレスでプロキシを構成することはおすすめできません。Google サービスは、時間の経過に伴って変化する場合がある多数の IP アドレスにマッピングされた DNS 名を介して公開されているため、一度だけの検索に基づいてプロキシを構成すると、Cloud Storage への接続が失敗することがあります。
プロキシ サーバーを介してリクエストをルーティングする場合は、ネットワーク管理者に確認して、プロキシによって認証情報を含む Authorization
ヘッダーが取り除かれないようにしてください。Authorization
ヘッダーがない場合、リクエストは拒否され、MissingSecurityHeader
エラーが発生します。
Storage Insights のエラー
問題: インベントリ レポートの構成で、毎日複数のインベントリ レポートが生成されます。
解決策: バケットに 1,000,000 個を超えるオブジェクトがある場合、複数のインベントリ レポートをシャードとして生成できます。インベントリ レポートの構成では、バケット内のオブジェクト 1,000,000 個ごとに 1 つのインベントリ レポートが生成されます。たとえば、3,500,000 個のオブジェクトを含むバケットがある場合、そのバケットのインベントリ レポートの構成では、指定した頻度で 4 つのインベントリ レポート シャードが生成されるほか、生成されたインベントリ レポート シャードの数とシャードのファイル名を含むマニフェスト ファイルも生成されます。
問題: インベントリ レポートが宛先バケットに表示されません。
解決策: インベントリ レポートの構成を作成しても、転送先バケットでインベントリ レポートが生成されない場合は、次の点を確認してください。
インベントリ レポートの構成で指定した開始日が、インベントリ レポートの生成日と一致していることを確認します。開始日の指定方法については、インベントリ レポート構成を作成するをご覧ください。
インベントリ レポートの履歴を表示して、不具合とその根本原因を確認します。インベントリ レポートの履歴を表示する手順は次のとおりです。
- Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
バケットのリストで、インベントリ レポートの構成を含むソースバケットの名前をクリックします。
[バケットの詳細] ページで、[インベントリ レポート] タブをクリックします。
インベントリ レポートの構成のリストで、確認するレポートを生成したインベントリ レポート構成の UUID をクリックします。
[インベントリ レポートの履歴] セクションで不具合を確認します。[ヘルプ](
)にカーソルを合わせると、不具合が発生した理由の詳細が表示されます。
- Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
プロジェクト レベルのサービス エージェントに、インベントリ レポートの読み取りと書き込みに必要な IAM ロールが付与されていることを確認します。手順については、サービス エージェントに必要なロールを付与するをご覧ください。
問題: インベントリ レポートの生成でランダムな遅延が発生します。
解決策: インベントリ レポートの生成間隔はさまざまです。最大で 1 日遅れることもあります。
次のステップ
- サポート オプションについて学習する。
- Cloud Storage に関するよくある質問のその他の質問の回答を確認する。
- Error Reporting が Cloud Storage のエラーの特定と把握にどのように役立つかを確認する。