Fehlerbehebung bei vollen Laufwerken und beim Anpassen der Größe von Laufwerken
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Linux
Auf dieser Seite werden häufige Probleme beschrieben, die bei der Größenanpassung eines nichtflüchtigen Speichers auftreten können oder wenn der nichtflüchtige Speicher voll ist. Außerdem wird erläutert, wie Sie diese beheben.
Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben.
Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud -Dienste und APIs überprüft. Zum Ausführen von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren:
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
Installieren Sie die Google Cloud CLI.
Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl:
Wenn Sie die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung verwenden möchten, nutzen Sie die Anmeldedaten, die Sie der gcloud CLI bereitstellen.
Installieren Sie die Google Cloud CLI.
Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl:
Fehler bei der Datenübertragungsrate beim Ändern eines Laufwerks
Die folgenden gängigen Fehler können auftreten, wenn Sie versuchen, Ihren extreme Persistent Disk oder Google Cloud Hyperdisk zu ändern. Diese Fehler können an verschiedenen Stellen angezeigt werden, z. B. in der Ausgabe der seriellen Konsole oder in Anwendungslogs.
Disk cannot be resized due to being rate limited.
Cannot update provisioned iops due to being rate limited.
Cannot update provisioned throughput due to being rate limited.
Beachten Sie die folgenden Zeitlimits für die Laufwerksumwandlung:
Sie können die Größe eines extrem nichtflüchtigen Speichers oder eines Hyperdisk Durchsatz-volume in einem Zeitraum von 6 Stunden nur einmal ändern.
Sie können die Größe eines Hyperdisk Extreme-Volumes in einem Zeitraum von 4 Stunden nur einmal ändern.
Sie können die bereitgestellten IOPS oder den bereitgestellten Durchsatz für ein Hyperdisk-Volume nur einmal in einem Zeitraum von vier Stunden ändern.
Um diese Fehler zu beheben, warten Sie die erforderliche Zeit seit der letzten Änderung ab, bevor Sie versuchen, die Laufwerke noch einmal zu ändern.
Fehler bei der Laufwerkskapazität
Volle Laufwerke
Die folgenden gängigen Fehler können auftreten, wenn der nichtflüchtige Speicher die volle Kapazität erreicht. Diese Fehler können an verschiedenen Stellen angezeigt werden, z. B. in der Ausgabe der seriellen Konsole oder in Anwendungslogs.
No space left on device
Not enough storage is available to process this command
VM aufgrund eines vollen Bootlaufwerks nicht zugänglich
Ihre VM ist möglicherweise nicht mehr zugänglich, wenn das Bootlaufwerk voll ist. Dieses Szenario kann schwierig zu identifizieren sein. Es ist nicht immer offensichtlich, ob das VM-Verbindungsproblem auf ein volles Bootlaufwerk zurückzuführen ist. Die folgenden Beispiele zeigen häufige Fehler, die auftreten können, wenn Sie nicht über Google Cloud CLI auf die VM zugreifen können, da das Bootlaufwerk voll ist:
Network error: Software caused connection abort
ERROR: (gcloud.compute.ssh) Could not SSH into the instance. It is possible
that your SSH key has not propagated to the instance yet. Try running this
command again. If you still cannot connect, verify that the firewall and
instance are set to accept ssh traffic.
You cannot connect to the VM instance because of an unexpected error. Wait a
few moments and then try again.
No space left on device
ERROR Exception calling the response handler. [Errno 2] No usable temporary
directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...
Gehen Sie folgendermaßen vor, um die oben genannten Probleme zu beheben:
Bestätigen Sie, dass der SSH-Fehler der VM auf ein volles Bootlaufwerk zurückzuführen ist:
Versuchen Sie noch einmal, eine SSH-Verbindung zur VM herzustellen.
Wenn Sie immer noch nicht auf die VM zugreifen können, führen Sie einen der folgenden Schritte aus:
Starten Sie die VM vorübergehend im Rettungsmodus: Verwenden Sie das Open-Source-GCE-Rescue-Tool und führen Sie die Schritte unter Dateisystemprobleme aus.
Probleme mit dem Dateisystem
Größe des Dateisystems anpassen
Nachdem Sie die Größe eines VM-Bootlaufwerks angepasst haben, ändern die meisten VMs die Größe des Stammdateisystems und starten die VM neu. Bei einigen VM-Image-Typen müssen Sie jedoch möglicherweise die Größe des Dateisystems manuell anpassen. Wenn Ihre VM keine automatische Größenanpassung des Stammdateisystems unterstützt oder Sie die Größe eines nichtflüchtigen Speichers (ohne Bootfunktion) angepasst haben, müssen Sie die Größe des Dateisystems und der Partitionen manuell anpassen.
So prüfen Sie, ob Ihr Stammdateisystem nach der Größenanpassung des VM-Bootlaufwerks automatisch maximiert wurde:
Prüfen Sie mit einer der folgenden Methoden, ob die Größe des Bootlaufwerks von Ihrer VM angepasst wurde:
Wenn auf VMs mit Debian-Images beispielsweise die automatische Größenänderung erfolgreich war, enthalten die Konsolenlogs die Zeile ... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.
Wenn Sie über SSH eine Verbindung zu einer Linux-VM herstellen können, führen Sie den Befehl df -h aus, um zu prüfen, ob freier Speicherplatz vorhanden ist.
Diese Ausgabe zeigt beispielsweise, dass das Stammdateisystem zu 92 % belegt ist:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis document outlines common issues encountered when resizing or managing full persistent disks in Linux environments.\u003c/p\u003e\n"],["\u003cp\u003eIt provides solutions for rate-limited errors when modifying Extreme Persistent Disks or Hyperdisks, including waiting for specific timeframes.\u003c/p\u003e\n"],["\u003cp\u003eThe content details how to address disk capacity errors, including full disks and inaccessible VMs due to a full boot disk, by creating snapshots, deleting unnecessary files, or resizing the disk.\u003c/p\u003e\n"],["\u003cp\u003eIt explains how to determine if a root file system was automatically resized after increasing a VM boot disk's size, and provides instructions for manually resizing the file system if needed.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot full disks and disk resizing\n\nLinux\n\n*** ** * ** ***\n\nThis page describes common issues that you might run into when resizing a\npersistent disk or when your persistent disk is full, and how to fix each of\nthem.\n\nBefore you begin\n----------------\n\n- Always [create a snapshot of\n your disk](/compute/docs/disks/create-snapshots) before performing any troubleshooting steps to ensure that your data is backed up.\n- If you haven't already, set up [authentication](/compute/docs/authentication). Authentication verifies your identity 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:\n\n Select the tab for how you plan to use the samples on this page: \n\n ### Console\n\n\n When you use the Google Cloud console to access Google Cloud services and\n APIs, you don't need to set up authentication.\n\n ### gcloud\n\n 1.\n [Install](/sdk/docs/install) the Google Cloud CLI.\n\n After installation,\n [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n ```bash\n gcloud init\n ```\n\n\n If you're using an external identity provider (IdP), you must first\n [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n | **Note:** If you installed the gcloud CLI previously, make sure you have the latest version by running `gcloud components update`.\n 2. [Set a default region and zone](/compute/docs/gcloud-compute#set_default_zone_and_region_in_your_local_client).\n\n ### REST\n\n\n To use the REST API samples on this page in a local development environment, you use the\n credentials you provide to the gcloud CLI.\n 1. [Install](/sdk/docs/install) the Google Cloud CLI. After installation, [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command: \n\n ```bash\n gcloud init\n ```\n 2. If you're using an external identity provider (IdP), you must first [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n\n For more information, see\n [Authenticate for using REST](/docs/authentication/rest)\n in the Google Cloud authentication documentation.\n\nRate limited error when modifying a disk\n----------------------------------------\n\nThe following are common errors you might encounter when you attempt to\nmodify your Extreme Persistent Disk or Google Cloud Hyperdisk. You might see these\nerrors appear in a number of places, such as in your serial console output or\nin application logs.\n\n```\nDisk cannot be resized due to being rate limited.\n``` \n\n```\nCannot update provisioned iops due to being rate limited.\n``` \n\n```\nCannot update provisioned throughput due to being rate limited.\n```\n\nReview the following time limits for modifying disks:\n\n- You can resize an Extreme Persistent Disk or Hyperdisk Throughput volume only once in a 6 hour period.\n- You can resize a Hyperdisk Extreme volume only once in a 4 hour period.\n- You can change the provisioned IOPS or throughput for a Hyperdisk volume only once in a 4 hour period.\n\nTo resolve these errors, wait the required amount of time since your last\nmodification before attempting to modify the disks again.\n\nDisk capacity errors\n--------------------\n\n### Full disks\n\nThe following are common errors you might encounter when your persistent disk\nreaches full capacity. You might see these errors appear in a number of places,\nsuch as in your serial console output or in application logs.\n\n```\nNo space left on device\n``` \n\n```\nNot enough storage is available to process this command\n```\n\nTo resolve this issue, do the following:\n\n1. [Create a snapshot](/compute/docs/disks/create-snapshots#creating_snapshots)\n of the disk.\n\n2. Delete files that you don't need on the disk to free up space.\n\n3. If your disk requires more space after this, [resize the disk](/compute/docs/disks/resize-persistent-disk).\n\n### Inaccessible VM due to full boot disk\n\nYour VM might become inaccessible if its boot disk is full. This scenario can be\ndifficult to identify; it's not always obvious when the VM connectivity issue\nis due to a full boot disk. The following are examples of common errors you\nmight encounter if you cannot access your VM from the Google Cloud CLI because\nthe boot disk is full:\n\n```\n Network error: Software caused connection abort\n \n``` \n\n```\n ERROR: (gcloud.compute.ssh) Could not SSH into the instance. It is possible\n that your SSH key has not propagated to the instance yet. Try running this\n command again. If you still cannot connect, verify that the firewall and\n instance are set to accept ssh traffic.\n \n``` \n\n```\n You cannot connect to the VM instance because of an unexpected error. Wait a\n few moments and then try again.\n \n``` \n\n```\n No space left on device\n \n``` \n\n```\n ERROR Exception calling the response handler. [Errno 2] No usable temporary\n directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...\n \n```\n\nTo resolve the above issues, do the following:\n\n1. Confirm that the VM's SSH failure is due to a full boot disk:\n\n ```\n gcloud compute instances tail-serial-port-output VM_NAME\n ```\n\n If the boot disk is full, the resulting output will contain the message `No\n space left on device`.\n2. If you have not already done so, [create a snapshot](/compute/docs/disks/create-snapshots#creating_snapshots)\n of the VM's boot disk.\n\n3. Try to [restart the VM](/compute/docs/instances/stop-start-instance#stopping_a_vm).\n\n4. If you still can't access the VM, do the following:\n\n 1. Stop the VM:\n\n ```\n gcloud compute instances stop VM_NAME\n ```\n\n Replace \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e with the name of your VM.\n 2. Increase the size of the boot disk:\n\n ```\n gcloud compute disks resize BOOT_DISK_NAME --size DISK_SIZE\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eBOOT_DISK_NAME\u003c/var\u003e: the name of your VM's boot disk\n - \u003cvar translate=\"no\"\u003eDISK_SIZE\u003c/var\u003e: the new larger size, in gigabytes, for the boot disk\n\n For example, to resize a disk named `example-disk-1` to 6GB, run\n the following command: \n\n ```\n gcloud compute disks resize example-disk-1 --size=6GB\n ```\n 3. Start the VM:\n\n ```\n gcloud compute instances start VM_NAME\n ```\n5. Reattempt to [SSH to the VM](/compute/docs/instances/connecting-to-instance).\n If you still can't access the VM, do one of the following:\n\n - Create a new disk from a snapshot. For more information, see\n [Recovering an inaccessible VM or a full boot disk](/compute/docs/disks/recover-vm#inaccessible_instance).\n\n - Boot the VM temporarily in rescue mode, using open source\n [GCE Rescue tool](https://github.com/googlecloudplatform/gce-rescue)\n and perform the steps available in [File system issues](#filesystem).\n\nFile system issues\n------------------\n\n### File system resize\n\nAfter you resize a VM boot disk, most VMs resize the root file system and\nrestart the VM. However, for some VM images types, you might have to resize the\nfile system manually. If your VM does not support automatic root file\nsystem resizing, or if you've resized a data (non-boot) persistent disk, you\nmust manually [resize the file system and partitions](/compute/docs/disks/resize-persistent-disk).\n\nTo check if your root file system expanded automatically after you resized your\nVM boot disk, do the following:\n\n1. Check if your VM resized the boot disk using one of the following methods:\n\n - [Inspect your serial port output](/compute/docs/instances/viewing-serial-port-output).\n Look for a line that indicates the root partition was resized.\n\n For example, on VMs with Debian images, if the automatic resize was\n successful then the console logs include the line\n `... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1`.\n - If you can connect to a Linux VM using SSH, run the command `df -h` to\n check if there is free disk space.\n\n For example, this output shows that the root file system is 92%\n full: \n\n ```\n Filesystem Size Used Avail Use% Mounted on\n udev 63G 0 63G 0% /dev\n tmpfs 13G 1.4M 13G 1% /run\n /dev/sda1 339G 315G 24G 92% /\n ```\n2. If your VM didn't resize the root file system, manually [resize the file\n system and partitions](/compute/docs/disks/resize-persistent-disk)."]]