Troubleshooting metadata server access issues

This document shows you how to resolve issues with the Compute Engine metadata server.

Compute Engine VMs store metadata on a metadata server. VMs automatically have access to the metadata server API without any additional authorization. However, sometimes VMs might lose access to the metadata server due to one of the following causes:

  • Failure to resolve the metadata server domain name
  • Connection to the metadata server is blocked by one of the following:
    • OS level firewall configuration
    • Proxy setup
    • Custom routing

When VMs can't access the metadata server, some processes might fail.

For information about troubleshooting the gke-metadata-server, see Troubleshoot GKE authentication issues.

Before you begin

  • If you haven't already, then set up authentication. Authentication is the process by which your identity is verified for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

    REST

    To use the REST API samples on this page in a local development environment, you use the credentials you provide to the gcloud CLI.

      Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init

    For more information, see Authenticate for using REST in the Google Cloud authentication documentation.

Troubleshoot server codes

The following server codes are returned when you make calls to the Compute Engine metadata server. Review this section to see how to respond to each server code returned by the metadata server.

Common server codes

These server codes are frequently returned from the metadata server.

Server code Description Resolution
200 OK: the request was successful N/A
400 Bad Request: this error status is returned for many different scenarios such as when a request has improper query parameters or requirements for that endpoint have not been met. Review the error message for suggestions on how to fix the error
404 Not Found: the requested endpoint doesn't exist Fix the request path
429 Too many requests: this occurs because some endpoints use rate limiting to prevent overloading on the backing service Wait a few seconds and retry the call
503 Service unavailable: the metadata server isn't ready to serve. The metadata server might return the Error 503 status code in any of the following circumstances:
  • The metadata server is still booting
  • The metadata server is in the process of migrating
  • The metadata server is temporarily unavailable
  • The host machine is performing a maintenance event
 503s are transient and should resolve after, at most, a few seconds. To resolve, wait a few seconds and retry the call.

Rare server codes

These server codes, though rare, might also be returned from the metadata server.

Server code Description Resolution
301 Moved Permanently: this is provided for paths that have redirects Update the request path
403 Forbidden: this is returned if the metadata server believes the request is not secure. This can happen if your TCP connection to the server was closed at the networking layer. Check your network configuration
405 Not Allowed: this error code is returned if an unsupported method is requested.

The metadata server only supports GET operations, with the exception of guest-writable metadata, which allows SET operations.		 Update the method in your request path

Retry guidance

The metadata server routinely returns 503 and 429 error codes. To make your applications resilient, we recommend that you implement retry logic for applications that query the metadata server. We also suggest that you implement exponential backoff in your scripts to account for any possible rate limiting.

Troubleshoot failed requests to the metadata server

The following are example errors that you might encounter if your VM fails to reach the metadata server:

curl: (6) Could not resolve host: metadata.google.internal

postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused

If your VM has lost access to the metadata server, do the following:

Linux

  1. Connect to your Linux VM.

  2. From your Linux VM, run the following commands to test connectivity to the metadata server:

    1. Query the Domain Name Server:

      nslookup metadata.google.internal

      The output should look similar to the following:

      Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254

    2. Check that the metadata server is reachable. To verify, run the following commands:

      ping -c 3 metadata.google.internal

      The output should look similar to the following:

      PING metadata.google.internal (169.254.169.254) 56(84) bytes of data.
64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms

      ping -c 3 169.254.169.254

      The output should look similar to the following:

      PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.
64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms

    3. If the output of the preceding commands matches the suggested output, your VM is connected to the metadata server and no further action is required. If the commands fail, do the following:

      1. Check that the name server is configured to the Metadata server:

        cat /etc/resolv.conf

        The output should look similar to the following:

        domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

        If the output doesn't have the preceding lines, refer to your operating system documentation for information about how to edit the DHCP Policy to persist the name server configuration to 169.254.169.254. This is because changes to /etc/resolv.conf will be overwritten in one hour if zonal DNS settings are applied to the VMs within your project. In case your project is still using a global DNS, the resolv.conf file will be reverted to the default DHCP in 24 hours.

      2. Check that the mapping between the metadata server domain name and its IP address exist:

        cat /etc/hosts

        The following line should be in the output:

        169.254.169.254 metadata.google.internal  # Added by Google

        If the output doesn't have the preceding line, run the following command:

        echo "169.254.169.254 metadata.google.internal" >> /etc/hosts

Windows

  1. Connect to your Windows VM.

  2. From your Windows VM, run the following commands:

    1. Query the Domain Name Server:

      nslookup metadata.google.internal

      The output should look similar to the following:

      Server:  UnKnown
Address:  10.128.0.1

Non-authoritative answer:
Name:    metadata.google.internal
Address:  169.254.169.254

    2. Check that the metadata server is reachable. To verify, run the following commands:

      ping -n 3 metadata.google.internal

      The output should look similar to the following: 

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255


      ping -n 3 169.254.169.254

      The output should look similar to the following:

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

    3. If the output of the preceding commands matches the suggested output, your VM is connected to the metadata server and no further action is required. If the commands fail, do the following:

      1. Check that there's a persistent route to the metadata server by running the command:

        route print

        The output should contain the following:

        Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1

        If the output doesn't have the preceding line, add the route using the following commands:

        $Adapters = Get-NetKVMAdapterRegistry
$FirstAdapter = $Adapters | Select-Object -First 1
route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1

      2. Check that the mapping between the metadata server domain name and its IP address exists:

        type %WINDIR%\System32\Drivers\Etc\Hosts

        The following line should be in the output:

        169.254.169.254 metadata.google.internal  # Added by Google

        If the output doesn't have the preceding line, run the following command:

        echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts

Troubleshoot failed requests while using a network proxy

A network proxy server prevents VM's direct access to the Internet. All queries sent from within a VM are handled by the proxy server instead.

When using an application that gets credentials from the metadata server, like an authentication token, the VM requires direct access to the metadata server. If the VM is behind a proxy, you must set the NO_PROXY configuration for both the IP address and Hostname.

If you don't set the NO_PROXY configuration, you might see errors when running Google Cloud CLI commands or querying the metadata server directly since the calls to metadata.google.internal will be sent to the proxy without having them resolved locally on the instance itself.

The following is an example of an error that you might see:

ERROR 403 (Forbidden): Your client does not have permission to get URL

To resolve this proxy issue, add the metadata server hostname and IP address to the environment variable NO_PROXY by doing the following:

Linux

  1. Connect to your Linux VM.

  2. From your Linux VM, run the following commands:

    export no_proxy=169.254.169.254,metadata,metadata.google.internal

    To save the changes, run the following command:

    echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment

Windows

  1. Connect to your Windows VM.

  2. From your Windows VM, run the following commands:

    set NO_PROXY=169.254.169.254,metadata,metadata.google.internal

    To save the changes, run the following command:

    setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m

Troubleshoot failed requests to the HTTPS metadata server endpoint

This section covers some of the errors that you might see when you are querying the HTTPS metadata server endpoint.

The errors listed in this section are returned when you query using the cURL tool to query, however the returned error message is similar for other tools.

Incorrect client certificate

The following errors occur if you provide an incorrect value for the -E flag.

  • curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate
required, errno 0
  • curl: (58)  unable to set private key file:
  • curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory

To resolve this issue, provide the correct path to the client identity certificate. To view the location for client identity certificates, see Client identity certificates.

Incorrect hostname

The following error occurs if the hostname used to access the metadata server isn't found on the certificate.

curl: (60) SSL: no alternative certificate subject name matches target host name

To resolve this issue, verify that the root URL or hostname in your query is metadata.google.internal. For more information about the root URL for the metadata server, see Parts of a metadata request.

Incorrect root or client certificate

You might see the following error when you query the HTTPS metadata server endpoint:

curl: (77) error setting certificate verify locations:

This might happen in the following scenarios:

  • The path for the --cacert flag might be malformed
  • The root certificate might be missing from the trust store

To resolve this issue, you need to specify both the root certificate and the client certificate when querying the https endpoint. For certificate locations, see Where are certificates stored.

For example, to query the boot image for a VM, run the following query:

user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \
    -E /run/google-mds-mtls/client.key \
    --cacert /run/google-mds-mtls/root.crt \
    -H "Metadata-Flavor: Google"

Troubleshoot incorrect header format

The metadata server performs formatting checks to ensure that headers comply with the header formatting guideline RFC 7230 Section 3.2. If the header format fails these checks the following occurs:

  • The request is accepted. However, you'll receive recommendations that you have VMs making requests to the metadata server with incorrectly formatted headers. Recommendations are sent once per VM. You can access these recommendations by using the Google Cloud CLI, or the Recommender REST API.

    After you have applied the recommendation, set the recommendation state to succeeded.

  • Starting January 20, 2024, the metadata server denies any request with an incorrectly formatted header.

The following shows examples of valid and invalid header request formats.

Not valid: contains whitespace between the header name and colon

Metadata-Flavor : Google

Valid: no whitespace between header name and colon, whitespace after the colon is ignored by the checker

Metadata-Flavor: Google

Valid: no whitespace in header

Metadata-Flavor:Google

For more information about making queries to metadata server, see Access VM metadata.