Stay organized with collections
Save and categorize content based on your preferences.
Linux
This page describes common issues that you might run into when resizing a
persistent disk or when your persistent disk is full, and how to fix each of
them.
Before you begin
Always create a snapshot of
your disk before performing any troubleshooting steps to ensure that your
data is backed up.
If you haven't already, set up 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:
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
Install the Google Cloud CLI.
After installation,
initialize the Google Cloud CLI by running the following command:
The following are common errors you might encounter when you attempt to
modify your Extreme Persistent Disk or Google Cloud Hyperdisk. You might see these
errors appear in a number of places, such as in your serial console output or
in application logs.
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.
Review the following time limits for modifying disks:
You can resize an Extreme Persistent Disk or Hyperdisk Throughput
volume only once in a 6 hour period.
You can resize a Hyperdisk Extreme volume only once in a 4
hour period.
You can change the provisioned IOPS or throughput for a
Hyperdisk volume only once in a 4 hour period.
To resolve these errors, wait the required amount of time since your last
modification before attempting to modify the disks again.
Disk capacity errors
Full disks
The following are common errors you might encounter when your persistent disk
reaches full capacity. You might see these errors appear in a number of places,
such as in your serial console output or in application logs.
No space left on device
Not enough storage is available to process this command
Delete files that you don't need on the disk to free up space.
If your disk requires more space after this, resize the disk.
Inaccessible VM due to full boot disk
Your VM might become inaccessible if its boot disk is full. This scenario can be
difficult to identify; it's not always obvious when the VM connectivity issue
is due to a full boot disk. The following are examples of common errors you
might encounter if you cannot access your VM from the Google Cloud CLI because
the boot disk is full:
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', '/']...
To resolve the above issues, do the following:
Confirm that the VM's SSH failure is due to a full boot disk:
After you resize a VM boot disk, most VMs resize the root file system and
restart the VM. However, for some VM images types, you might have to resize the
file system manually. If your VM does not support automatic root file
system resizing, or if you've resized a data (non-boot) persistent disk, you
must manually resize the file system and partitions.
To check if your root file system expanded automatically after you resized your
VM boot disk, do the following:
Check if your VM resized the boot disk using one of the following methods:
For example, on VMs with Debian images, if the automatic resize was
successful then the console logs include the line
... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.
If you can connect to a Linux VM using SSH, run the command df -h to
check if there is free disk space.
For example, this output shows that the root file system is 92%
full:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 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)."]]
