Resolução de problemas

Esta página descreve os métodos de resolução de problemas para erros comuns que pode encontrar ao usar o Cloud Storage.

Consulte o Google Cloud Painel de controlo do estado do serviço para ver informações sobre incidentes que afetam Google Cloud serviços como o Cloud Storage.

Registo de pedidos não processados

Importante: nunca partilhe as suas credenciais. Quando imprime detalhes do protocolo HTTP, as suas credenciais de autenticação, como tokens OAuth 2.0, ficam visíveis nos cabeçalhos. Se precisar de publicar detalhes de pedidos ou respostas num fórum de mensagens ou fornecê-los para resolução de problemas, certifique-se de que limpa ou revoga todas as credenciais que aparecem como parte do resultado.

Quando usa ferramentas como gcloud ou as bibliotecas de cliente do Cloud Storage, grande parte das informações de pedido e resposta são processadas pela ferramenta. No entanto, por vezes, é útil ver detalhes para ajudar na resolução de problemas ou quando publica perguntas em fóruns como o Stack Overflow. Use as instruções seguintes para devolver os cabeçalhos de pedido e resposta da sua ferramenta:

Consola

A visualização das informações de pedidos e respostas depende do navegador que está a usar para aceder à Google Cloud consola. Para o navegador Google Chrome:

1. Clique no botão do menu principal do Chrome ().

2. Selecione Mais ferramentas.

3. Clique em Ferramentas para programadores.

4. No painel apresentado, clique no separador Rede.

Linha de comandos

Use flags de depuração globais no seu pedido. Por exemplo:

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

Bibliotecas cliente

C++

• Defina a variável de ambiente CLOUD_STORAGE_ENABLE_TRACING=http para receber o tráfego HTTP completo.

• Defina a variável de ambiente CLOUD_STORAGE_ENABLE_CLOG=yes para obter o registo de cada RPC.

C#

Adicione um registador através de ApplicationContext.RegisterLogger e defina as opções de registo no controlador de mensagens HttpClient. Para mais informações, consulte a documentação de referência da biblioteca de cliente C#.

Go

Defina a variável de ambiente GODEBUG=http2debug=1. Para mais informações, consulte o pacote Go net/http.

Se também quiser registar o corpo do pedido, use um cliente HTTP personalizado.

Java

1. Crie um ficheiro denominado "logging.properties" com o seguinte conteúdo:

   # 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

2. Use o ficheiro logging.properties com o Maven

   mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command

Para mais informações, consulte o artigo Transporte HTTP conectável.

Node.js

Defina a variável de ambiente NODE_DEBUG=https antes de chamar o script do Node.

PHP

Forneça o seu próprio controlador HTTP ao cliente através de httpHandler e configure o middleware para registar o pedido e a resposta.

Python

Use o módulo de registo. Por exemplo:

import logging
import http.client

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

Ruby

Na parte superior do .rb file depois de require "google/cloud/storage", adicione o seguinte:

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

Adicionar cabeçalhos personalizados

A adição de cabeçalhos personalizados a pedidos é uma ferramenta comum para fins de depuração, como para ativar cabeçalhos de depuração ou para rastrear um pedido. O exemplo seguinte mostra como definir cabeçalhos de pedidos para diferentes ferramentas do Cloud Storage:

Linha de comandos

Use a flag --additional-headers, que está disponível para a maioria dos comandos. Por exemplo:

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

Onde HEADER_NAME e HEADER_VALUE definem o cabeçalho que está a adicionar ao pedido.

Nota: a flag --additional-headers não está disponível para todos os comandos, como os comandos que funcionam com políticas de gestão de identidade e de acesso (IAM) e comandos buckets notifications.

gcloud storage

Bibliotecas cliente

C++

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

Nota: a biblioteca cliente C++ suporta apenas um cabeçalho personalizado de cada vez.

C#

O exemplo seguinte adiciona um cabeçalho personalizado a cada pedido feito pela biblioteca cliente.

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

Pode adicionar cabeçalhos personalizados a qualquer chamada API feita pelo pacote Storage usando callctx.SetHeaders no contexto que é transmitido ao método.

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.
  }
}

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

Todas as chamadas de métodos que acionam pedidos http aceitam um argumento $restOptions opcional como o último argumento. Pode fornecer cabeçalhos personalizados por pedido ou por cliente.

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' }

Aceder a contentores com uma configuração de CORS

Se tiver definido uma configuração de CORS no seu contentor e reparar que os pedidos recebidos de navegadores de clientes estão a falhar, experimente os seguintes passos de resolução de problemas:

1. Reveja a configuração de CORS no contentor de destino. Se existirem várias entradas de configuração de CORS, certifique-se de que os valores de pedido que usa para a resolução de problemas são mapeados para valores numa única entrada de configuração de CORS.

2. Quando testar a emissão de um pedido CORS, verifique se não está a fazer um pedido para o ponto final storage.cloud.google.com, que não permite pedidos CORS. Para mais informações sobre os pontos finais suportados para CORS, consulte o artigo Suporte de CORS do Cloud Storage.

3. Reveja um pedido e uma resposta através da ferramenta da sua escolha. Num navegador Chrome, pode usar as ferramentas para programadores padrão para ver estas informações:

   1. Clique no menu do Chrome () na barra de ferramentas do navegador.
   2. Selecione Mais ferramentas > Ferramentas para programadores.
   3. Clique no separador Rede.
   4. A partir da sua aplicação ou linha de comandos, envie o pedido.
   5. No painel que apresenta a atividade de rede, localize o pedido.
   6. Na coluna Nome, clique no nome correspondente ao pedido.
   7. Clique no separador Cabeçalhos para ver os cabeçalhos de resposta ou no separador Resposta para ver o conteúdo da resposta.

   Se não vir um pedido e uma resposta, é possível que o seu navegador tenha colocado em cache uma tentativa anterior de pedido de pré-voo com falha. A limpeza da cache do navegador também deve limpar a cache de pré-voo. Se não for, defina o valor MaxAgeSec na configuração CORS para um valor inferior ao valor predefinido de 1800 (30 minutos), aguarde o tempo do MaxAgeSec antigo e, em seguida, tente o pedido novamente. Isto executa um novo pedido de verificação prévia, que obtém a nova configuração do CORS e limpa as entradas da cache. Depois de depurar o problema, aumente novamente o valor de MaxAgeSec para reduzir o tráfego de pré-lançamento para o seu contentor.

4. Certifique-se de que o pedido tem um cabeçalho Origin e que o valor do cabeçalho corresponde, pelo menos, a um dos valores Origins na configuração de CORS do contentor. Tenha em atenção que o esquema, o anfitrião e a porta dos valores têm de corresponder exatamente. Seguem-se alguns exemplos de correspondências aceitáveis:

   • http://origin.example.com corresponde a http://origin.example.com:80 (porque 80 é a porta HTTP predefinida), mas não corresponde a https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 nem http://sub.origin.example.com.

   • https://example.com:443 corresponde a https://example.com, mas não a http://example.com nem a http://example.com:443.

   • http://localhost:8080 só corresponde exatamente a http://localhost:8080 e não corresponde a http://localhost:5555 nem a http://localhost.example.com:8080.

5. Para pedidos simples, certifique-se de que o método HTTP do pedido corresponde a, pelo menos, um dos valores Methods na configuração de CORS do contentor. Para pedidos de pré-voo, certifique-se de que o método especificado em Access-Control-Request-Method corresponde, pelo menos, a um dos valores de Methods.

6. Para pedidos de verificação prévia, verifique se inclui um ou mais cabeçalhos Access-Control-Request-Header. Se for o caso, certifique-se de que cada valor Access-Control-Request-Header corresponde a um valor ResponseHeader na configuração CORS do contentor. Todos os cabeçalhos com nome no elemento Access-Control-Request-Header têm de estar na configuração CORS para que o pedido de verificação prévia seja bem-sucedido e inclua cabeçalhos CORS na resposta.

Códigos de erro

Seguem-se códigos de estado HTTP comuns que pode encontrar.

301: Movido permanentemente

Problema: estou a configurar um Website estático e o acesso a um caminho de diretório devolve um objeto vazio e um código de resposta HTTP 301.

Solução: se o seu navegador transferir um objeto de zero bytes e receber um 301código de resposta HTTP quando aceder a um diretório, como http://www.example.com/dir/, é muito provável que o seu contentor contenha um objeto vazio com esse nome. Para verificar se é este o caso e corrigir o problema:

1. Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.
   

   Aceda a Recipientes

2. Clique no botão Ativar Cloud Shell na parte superior da Google Cloud consola.
3. Corrida gcloud storage ls --recursive gs://www.example.com/dir/. Se o resultado incluir http://www.example.com/dir/, tem um objeto vazio nessa localização.
4. Remova o objeto vazio com o comando: gcloud storage rm gs://www.example.com/dir/

Agora, pode aceder a http://www.example.com/dir/ e fazer com que devolva o ficheiro index.html do diretório em vez do objeto vazio.

400: Pedido errado

Problema: ao fazer um carregamento retomável, recebi este erro e a mensagem Failed to parse Content-Range header.

Solução: o valor que usou no cabeçalho Content-Range é inválido. Por exemplo, Content-Range: */* é inválido e, em alternativa, deve ser especificado como Content-Range: bytes */*. Se receber este erro, o carregamento retomável atual já não está ativo e tem de iniciar um novo carregamento retomável.

400: erros específicos da inteligência de armazenamento

As secções seguintes descrevem erros comuns que pode encontrar quando configura ou gere a inteligência de armazenamento para um recurso.

400: nome do contentor inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem The specific bucket is not valid.

Solução: o URL que usou no pedido é inválido. O URL tem de cumprir os seguintes requisitos:

• locations/global é a única localização suportada para a inteligência de armazenamento. A utilização de qualquer outra localização não é suportada.
• Storage Intelligence está no singular no URL e não no plural.

Segue-se um exemplo de um URL válido:

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: Invalid Argument - Empty Update Mask

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Empty UPDATE_MASK in the request.

Solução: UPDATE_MASK é a lista de nomes de campos separados por vírgulas que o pedido atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso StorageIntelligence. Para atualizar a configuração do Storage Intelligence de um recurso, use um UPDATE_MASK válido no pedido. Não é suportado um valor vazio.

400: caminho da máscara de atualização inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid UPDATE_MASK paths.

Solução: se usar um nome de campo inválido no UPDATE_MASK, recebe uma mensagem de erro. UPDATE_MASK é a lista separada por vírgulas dos nomes dos campos que a solicitação atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso IntelligenceConfig. Para atualizar a configuração da inteligência de armazenamento de um recurso, certifique-se de que todos os nomes de campos indicados em UPDATE_MASK são campos válidos no recurso IntelligenceConfig.

400: Field Is Not Editable

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

Solução: UPDATE_MASK é a lista de nomes de campos separados por vírgulas que o pedido atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso IntelligenceConfig. Se tentar atualizar um campo que não é editável, recebe uma mensagem de erro. Remova o campo não editável de Update_Mask e tente novamente.

400: valor inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid value at storage_intelligence.edition_config.

Solução: se tentar usar um valor inválido para o campo edition_config, recebe uma mensagem de erro. Os valores permitidos são INHERIT, STANDARD e DISABLED. Reveja o valor e tente novamente.

400: filtro não vazio

Problema: quando atualiza a configuração da inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

Solução: quando atualiza o Storage Intelligence edition_config para INHERIT ou DISABLED, não pode usar filtros de contentores no pedido. Remova os filtros do pedido e tente novamente.

400: Empty Location Or Bucket Values In Filter

Problema: quando atualiza a configuração da inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Empty location or bucket values in filter.

Solução: quando atualiza a configuração da Storage Intelligence e usa um filtro de contentores no pedido, ocorre um erro se o valor de location ou bucket for uma string vazia. Indique um valor válido para location ou bucket e tente novamente.

401: não autorizado

Problema: os pedidos a um contentor público diretamente ou através do Cloud CDN estão a falhar com uma resposta HTTP 401: Unauthorized e Authentication Required.

Solução: verifique se o seu cliente ou qualquer proxy intermédio não está a adicionar um cabeçalho Authorization às solicitações para o Cloud Storage. Qualquer pedido com um cabeçalho Authorization, mesmo que esteja vazio, é validado como se fosse uma tentativa de autenticação.

403: conta desativada

Problema: tentei criar um contentor, mas recebi um erro 403 Account Disabled.

Solução: este erro indica que ainda não ativou a faturação para o projeto associado. Para ver os passos para ativar a faturação, consulte o artigo Ative a faturação para um projeto.

Se a faturação estiver ativada e continuar a receber esta mensagem de erro, pode contactar o apoio técnico com o seu ID do projeto e uma descrição do seu problema.

403: Proibido

Problema: devia ter autorização para aceder a um determinado contentor ou objeto, mas, quando tento fazê-lo, recebo um erro 403 - Forbidden com uma mensagem semelhante a: [e-mail] does not have storage.objects.get access to the Google Cloud Storage object.

Solução: não tem uma autorização de IAM para o contentor ou o objeto necessária para concluir o pedido. Se espera poder fazer o pedido, mas não consegue, faça as seguintes verificações:

1. O beneficiário referenciado na mensagem de erro é o que esperava? Se a mensagem de erro se referir a um endereço de email inesperado ou a "Autor anónimo", o seu pedido não está a usar as credenciais pretendidas. Isto pode dever-se ao facto de a ferramenta que está a usar para fazer o pedido ter sido configurada com as credenciais de outro alias ou entidade, ou o pedido pode estar a ser feito em seu nome por uma conta de serviço.

2. A autorização referenciada na mensagem de erro é uma autorização que pensava que precisava? Se a autorização for inesperada, é provável que a ferramenta que está a usar precise de acesso adicional para concluir o seu pedido. Por exemplo, para eliminar objetos em massa num contentor, o gcloud tem primeiro de criar uma lista de objetos no contentor a eliminar. Esta parte da ação de eliminação em massa requer a autorização storage.objects.list, o que pode ser surpreendente, uma vez que o objetivo é a eliminação de objetos, que normalmente requer apenas a autorização storage.objects.delete. Se esta for a causa da sua mensagem de erro, certifique-se de que lhe são concedidas funções do IAM que tenham as autorizações adicionais necessárias.

3. Tem a função IAM no recurso pretendido ou no recurso principal? Por exemplo, se lhe for concedido o papel Storage Object Viewer para um projeto e estiver a tentar transferir um objeto, certifique-se de que o objeto está num contentor que se encontra no projeto. Pode ter inadvertidamente a autorização Storage Object Viewer para um projeto diferente.

4. A sua autorização para aceder a um determinado contentor ou objeto é concedida através de um valor de conveniência? A remoção do acesso concedido a um valor de conveniência pode fazer com que os diretores anteriormente ativados percam o acesso aos recursos.

   Por exemplo, suponhamos que [e-mail] tem a função básica de proprietário (roles/owner) para um projeto denominado my-example-project e que a política de IAM do projeto concede a função de criador de objetos de armazenamento (roles/storage.objectCreator) ao valor de conveniência projectOwner:my-example-project. Isto significa que [e-mail] tem as autorizações associadas à função de criador de objetos de armazenamento para contentores em my-example-project. Se esta concessão for removida, [e-mail] perde as autorizações associadas à função de criador de objetos de armazenamento.

   Neste caso, pode recuperar o acesso ao contentor ou ao objeto concedendo-se as autorizações necessárias ao nível do contentor ou do objeto para realizar as ações de que precisa.

5. Existe uma política de negação do IAM que impede a utilização de determinadas autorizações? Pode contactar o administrador da sua organização para saber se foi implementada uma política de recusa do IAM.

403: autorização recusada

Problema: erro de acesso recusado quando configura ou gere a configuração da Storage Intelligence para um recurso.

Solução: se receber um erro de acesso recusado com uma mensagem semelhante a permission storage.intelligenceConfigs.update quando configurar e gerir a inteligência de armazenamento para um recurso, consulte a secção de autorizações para a operação que quer realizar. Para resolver este problema, conceda as autorizações adequadas. Pode conceder autorizações de qualquer uma das seguintes formas:

• Conceda autorizações de IAM na mesma hierarquia de recursosGoogle Cloud que está a ativar a inteligência de armazenamento.
• Certifique-se de que um recurso mais elevado na Google Cloud hierarquia de recursos transmite as autorizações ao recurso secundário.

409: Conflito

Problema: tentei criar um contentor, mas recebi o seguinte erro:

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

Solução: o nome do contentor que tentou usar (por exemplo, gs://cats ou gs://dogs) já está a ser usado. O Cloud Storage tem um espaço de nomes global, pelo que não pode dar a um contentor o mesmo nome de um contentor existente. Escolha um nome que não esteja a ser usado.

412: restrições personalizadas violadas

Problema: os meus pedidos estão a ser rejeitados com um erro 412 orgpolicy.

Problema: os meus pedidos estão a ser rejeitados com um erro 412 Multiple constraints were violated.

Solução: verifique junto da sua equipa de administração de segurança se o contentor para o qual está a enviar pedidos está a ser afetado por uma política da organização que usa uma restrição personalizada. O seu contentor também pode ser afetado por diferentes políticas organizacionais que entram em conflito entre si. Por exemplo, quando uma política especifica que os contentores têm de ter a classe de armazenamento Standard e outra política especifica que os contentores têm de ter a classe de armazenamento Coldline.

429: demasiados pedidos

Problema: os meus pedidos estão a ser rejeitados com um erro 429 Too Many Requests.

Solução: está a atingir um limite para o número de pedidos que o Cloud Storage permite para um determinado recurso. Consulte as quotas do Cloud Storage para uma discussão sobre os limites no Cloud Storage.

• Se a sua carga de trabalho consistir em milhares de pedidos por segundo para um contentor, consulte as diretrizes de taxa de pedidos e distribuição de acesso para uma discussão das práticas recomendadas, incluindo o aumento gradual da carga de trabalho e a evicção de nomes de ficheiros sequenciais.

• Se a sua carga de trabalho estiver potencialmente a usar 50 Gbps ou mais de saída de rede para localizações específicas, verifique a sua utilização de largura de banda para garantir que não está a ter problemas com uma quota de largura de banda.

Diagnosticar Google Cloud erros da consola

Problema: quando uso a Google Cloud consola para realizar uma operação, recebo uma mensagem de erro genérica. Por exemplo, vejo uma mensagem de erro quando tento eliminar um contentor, mas não vejo detalhes sobre o motivo da falha da operação.

Solução: use as notificações da Google Cloud consola Google Cloud para ver informações detalhadas sobre a operação com falha:

1. Clique no botão Notificações () no Google Cloud cabeçalho da consola.

   Um menu pendente apresenta as operações mais recentes realizadas pela Google Cloud consola.

2. Clique no item sobre o qual quer saber mais.

   É apresentada uma página com informações detalhadas sobre a operação.

3. Clique em cada linha para expandir as informações detalhadas sobre o erro.

Problema: quando uso a Google Cloud consola, não vejo uma coluna específica apresentada.

Solução: para ver uma coluna específica apresentada na Google Cloud consola, clique no ícone Opções de apresentação de colunas () e selecione a coluna que quer ver apresentada.

Pastas simuladas e pastas geridas

Problema: eliminei alguns objetos no meu contentor e, agora, a pasta que os continha não aparece na Google Cloud consola.

Solução: embora a Google Cloud consola apresente o conteúdo do seu contentor como se existisse uma estrutura de diretórios, as pastas não existem fundamentalmente no Cloud Storage. Como resultado, quando remove todos os objetos com um prefixo comum de um contentor, o ícone da pasta que representa esse grupo de objetos deixa de aparecer na consola. Google Cloud

Problema: não consigo criar pastas geridas.

Solução: para criar pastas geridas, certifique-se de que os seguintes requisitos são cumpridos:

• Tem uma função de IAM que contém a autorização storage.managedfolders.create, como a função de administrador de objetos de armazenamento (roles/storage.objectAdmin). Para ver instruções sobre como conceder funções, consulte o artigo Use autorizações de IAM.

• O acesso uniforme ao nível do contentor está ativado no contentor no qual quer criar pastas geridas.

• Não existem condições de IAM no contentor ou no projeto que usem o tipo de recurso de contentor (storage.googleapis.com/Bucket) ou o tipo de recurso de objeto (storage.googleapis.com/Object). Se algum contentor num projeto tiver uma condição de IAM que use qualquer um destes tipos de recursos, não é possível criar pastas geridas em nenhum dos contentores nesse projeto, mesmo que a condição seja removida posteriormente.

Problema: não consigo desativar o acesso uniforme ao nível do contentor porque existem pastas geridas no meu contentor.

Solução: não é possível desativar o acesso uniforme ao nível do contentor se existirem pastas geridas no contentor. Para desativar o acesso uniforme ao nível do contentor, tem de eliminar primeiro todas as pastas geridas no contentor.

Erros de websites estáticos

Seguem-se problemas comuns que pode encontrar quando configura um contentor para alojar um Website estático.

Publicação por HTTPS

Problema: quero publicar o meu conteúdo através de HTTPS sem usar um balanceador de carga.

Solução: pode publicar conteúdo estático através de HTTPS com URIs diretos, como https://storage.googleapis.com/my-bucket/my-object. Para outras opções de publicação do seu conteúdo através de um domínio personalizado por SSL, pode:

• Use uma rede de fornecimento de conteúdo de terceiros com o Cloud Storage.
• Publicar o conteúdo do seu Website estático a partir do Firebase Hosting em vez do Cloud Storage.

Página inacessível

Problema: recebo uma mensagem de erro Access denied para uma página Web publicada pelo meu Website.

Solução: verifique se o objeto é partilhado publicamente. Se não for, consulte o artigo Tornar os dados públicos para ver instruções sobre como o fazer.

Se carregou e partilhou anteriormente um objeto, mas depois carregou uma nova versão deste, tem de voltar a partilhar o objeto publicamente. Isto deve-se ao facto de a autorização pública ser substituída pelo novo carregamento.

Transferência de conteúdo

Problema: é-me pedido que transfira o conteúdo da minha página, em vez de o poder ver no navegador.

Solução: se especificar um MainPageSuffix como um objeto que não tem um tipo de conteúdo Web, os visitantes do site são solicitados a transferir o conteúdo em vez de poderem ver o conteúdo da página publicado. Para resolver este problema, atualize a entrada de metadados Content-Type para um valor adequado, como text/html. Para ver instruções, consulte o artigo Editar metadados de objetos.

Tornar os dados públicos

Problema: estou a tentar tornar os meus dados públicos, mas recebo um erro de política da organização.

Solução: algumas restrições de políticas da organização podem impedir que torne os seus dados públicos. Por exemplo, a restrição de partilha restrita ao domínio (constraints/iam.allowedPolicyMemberDomains) restringe a partilha de recursos com base no domínio da organização. Para falhas da política de organização, contacte o seu administrador para lhe conceder as autorizações ao nível do projeto ou do contentor para permitir a partilha de recursos editando a política de organização para o recurso de organização, pasta ou projeto. Se continuar a ver este erro depois de substituir a política da organização, pode ter de aguardar alguns minutos para que a alteração entre em vigor.

Problema: recebo um erro de autorização quando tento tornar os meus dados públicos.

Solução: certifique-se de que tem a autorização storage.buckets.setIamPolicy ou a autorização storage.objects.setIamPolicy. Estas autorizações são concedidas, por exemplo, na função de administrador de armazenamento (roles/storage.admin). Se tiver a autorização storage.buckets.setIamPolicy ou a autorização storage.objects.setIamPolicy e continuar a receber um erro, o seu contentor pode estar sujeito à prevenção de acesso público, que não permite o acesso a allUsers nem a allAuthenticatedUsers. A prevenção de acesso público pode ser definida diretamente no contentor ou pode ser aplicada através de uma política da organização definida a um nível superior.

Latência

Seguem-se problemas de latência comuns que pode encontrar. Além disso, o Google Cloud painel de controlo do estado do serviço fornece informações sobre incidentes que afetam os Google Cloud serviços, como o Cloud Storage.

Latência de carregamento ou transferência

Problema: estou a verificar um aumento da latência ao carregar ou transferir ficheiros.

Solução: considere as seguintes causas comuns de latência de carregamento e transferência:

• Restrições de CPU ou memória: o sistema operativo do ambiente afetado deve ter ferramentas para medir o consumo de recursos locais, como a utilização da CPU e a utilização de memória.

• Restrições de E/S de disco: o impacto no desempenho pode ser causado pela E/S de disco local.

• Distância geográfica: o desempenho pode ser afetado pela separação física do contentor do Cloud Storage e do ambiente afetado, particularmente em casos intercontinentais. Os testes com um contentor localizado na mesma região que o ambiente afetado podem identificar a medida em que a separação geográfica está a contribuir para a latência.

  • Se aplicável, o resolvedor de DNS do ambiente afetado deve usar o protocolo EDNS(0) para que os pedidos do ambiente sejam encaminhados através de um front-end da Google adequado.

Latência da CLI ou da biblioteca cliente

Problema: estou a observar um aumento da latência ao aceder ao Cloud Storage com a CLI Google Cloud ou uma das bibliotecas de cliente.

Solução: a CLI gcloud e as bibliotecas de cliente voltam a tentar automaticamente os pedidos quando é útil fazê-lo, e este comportamento pode aumentar eficazmente a latência vista pelo utilizador final. Use a métrica do Cloud Monitoring storage.googleapis.com/api/request_count para ver se o Cloud Storage está a publicar consistentemente um código de resposta repetível, como 429 ou 5xx.

Servidores proxy

Problema: estou a estabelecer ligação através de um servidor proxy. O que necessito de fazer?

Solução: para aceder ao Cloud Storage através de um servidor proxy, tem de permitir o acesso a estes domínios:

• accounts.google.com para criar símbolos de autenticação OAuth2
• oauth2.googleapis.com para realizar trocas de tokens OAuth2
• *.googleapis.com para pedidos de armazenamento

Se o seu servidor proxy ou política de segurança não suportar a adição de domínios à lista de autorizações e, em alternativa, suportar apenas a adição de blocos de rede IP à lista de autorizações, recomendamos vivamente que configure o seu servidor proxy para todos os intervalos de endereços IP da Google. Pode encontrar os intervalos de endereços consultando os dados do WHOIS no ARIN. Como prática recomendada, deve rever periodicamente as definições de proxy para garantir que correspondem aos endereços IP da Google.

Não recomendamos que configure o seu proxy com endereços IP individuais que obtém de pesquisas únicas de oauth2.googleapis.com e storage.googleapis.com. Uma vez que os serviços Google são expostos através de nomes DNS que mapeiam um grande número de endereços IP que podem mudar ao longo do tempo, a configuração do proxy com base numa pesquisa única pode levar a falhas na ligação ao Cloud Storage.

Se os seus pedidos estiverem a ser encaminhados através de um servidor proxy, pode ter de contactar o administrador de rede para garantir que o cabeçalho que contém as suas credenciais não é removido pelo proxy.Authorization Sem o cabeçalho Authorization, os seus pedidos são rejeitados e recebe um erro MissingSecurityHeader.

Erros das Estatísticas de armazenamento

Problema: a configuração do meu relatório de inventário está a gerar vários relatórios de inventário diariamente.

Solução: se tiver mais de 1 000 000 de objetos no seu contentor, podem ser gerados vários relatórios de inventário como fragmentos. Uma configuração de relatório de inventário gera um relatório de inventário para cada 1 000 000 de objetos no contentor. Por exemplo, se tiver um contentor com 3 500 000 objetos, a configuração do relatório de inventário no contentor gera quatro fragmentos do relatório de inventário de acordo com a frequência especificada, juntamente com um ficheiro de manifesto que contém o número de fragmentos do relatório de inventário gerados e os respetivos nomes de ficheiros.

Problema: os relatórios de inventário não aparecem no contentor de destino.

Solução: se criou uma configuração de relatório de inventário e não vê relatórios de inventário a serem gerados no contentor de destino, verifique o seguinte:

• Certifique-se de que a data de início especificada na configuração do relatório de inventário corresponde à data em que espera que os relatórios de inventário sejam gerados. Para ver instruções sobre como especificar uma data de início, consulte o artigo Crie uma configuração de relatório de inventário.

• Veja o histórico de relatórios de inventário para verificar se existem falhas e as respetivas causas principais. Para ver o histórico do relatório de inventário, conclua os seguintes passos:

  1. Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.
     

     Aceda a Recipientes

  2. Na lista de contentores, clique no nome do contentor de origem que contém a configuração do relatório de inventário.

  3. Na página Detalhes do contentor, clique no separador Relatórios de inventário.

  4. Na lista de configurações de relatórios de inventário, clique no UUID da configuração de relatório de inventário que gerou os relatórios que quer verificar.

  5. Verifique se existem falhas na secção Histórico do relatório de inventário. Pode manter o ponteiro sobre Ajuda () para ver detalhes sobre o motivo pelo qual ocorreu uma falha.

• Certifique-se de que o agente de serviço ao nível do projeto tem as funções de IAM necessárias para ler e escrever relatórios de inventário. Para obter instruções, consulte o artigo Conceda as funções necessárias ao agente do serviço.

Problema: estou a ver atrasos aleatórios na geração de relatórios de inventário.

Solução: o intervalo de tempo entre a geração dos relatórios de inventário pode variar. Pode haver um atraso de até um dia.

O que se segue?

• Encontre respostas a perguntas adicionais nas Perguntas frequentes do Cloud Storage.
• Saiba mais sobre as suas opções de apoio técnico.
• Explore como os relatórios de erros podem ajudar a identificar e compreender os erros do Cloud Storage.