Resizing a macOS VM’s APFS boot drive to use all available disk space
A while back, I wrote a post on how to resize the boot drive of an existing virtual machine. However, that guidance only applies to a boot drive that uses HFS+ for its filesystem.
Now that Apple File System (APFS) is available and the default file system on macOS High Sierra, a different procedure must be used in order to resize the APFS-formatted boot drive of an existing virtual machine. For more details, see below the jump.
For an APFS boot drive, you need to do two things:
1. Identify the appropriate APFS container:
APFS containers act as storage pools for APFS volumes. APFS volumes are what act as the mounted filesystem, where you store your files, directories, metadata, etc. When you grow the APFS container, the APFS volumes will likewise get additional space.
To identify the container for the boot volume, use the diskutil command shown below:
/usr/sbin/diskutil info / | awk '/Part of Whole/ {print $4}'
2. Once the appropriate APFS container has been identified, use the diskutil command shown below to resize the container with all available disk space.
Note: You can specify a size of zero (0) to grow the targeted container using all unallocated drive space.
/usr/sbin/diskutil apfs resizeContainer /dev/apfs_container_id_goes_here 0
In this example, I have a VM where my APFS-formatted boot drive is using 42.7 GBs of space, but the VM disk has 85.9 GBs of available space.
Assuming that the command above gave us disk1 as a result, the command shown below can be used to resize the boot drive’s APFS container with all available disk space.
/usr/sbin/diskutil apfs resizeContainer /dev/disk1 0
Once the container resizing has completed, the OS should now recognize and be able to use the newly-allocated space.
I’ve updated an existing script to identify if a boot drive is running HFS+ or APFS, then run the appropriate diskutil commands for that filesystem. It is available below and on my GitHub repo:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/resize_vm_boot_partition
This script is also available as a payload-free package on my GitHub repo, available for download from the payload_free_package directory available from the link above.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/bin/bash | |
# This script is designed for use with virtual machines which | |
# need to resize their boot volumes. The script checks the boot | |
# volume using the diskutil info command and detects if the boot | |
# volume is using HFS+ or APFS for the boot volume's filesystem. | |
# | |
# If the boot volume is using HFS+ for its filesystem, the | |
# diskutil resize command is used to assign the boot volume | |
# all available free space. | |
# | |
# If the boot volume is using APFS for its filesystem, the | |
# diskutil info command is used again to get the appropriate | |
# APFS container ID. Once the container ID is available, the | |
# diskutil apfs resizeContainer command is used to assign the | |
# boot volume's host container all available free space. | |
ERROR=0 | |
boot_filesystem_check=$(/usr/sbin/diskutil info / | awk '/Type \(Bundle\)/ {print $3}') | |
if [[ "$boot_filesystem_check" = "hfs" ]]; then | |
# Use the diskutil resize command to assign | |
# all available free space on the drive to | |
# the HFS+ boot volume. | |
/usr/sbin/diskutil resizeVolume / R | |
elif [[ "$boot_filesystem_check" = "apfs" ]]; then | |
# Get APFS container ID on boot drive | |
apfs_container_id=$(/usr/sbin/diskutil info / | awk '/Part of Whole/ {print $4}') | |
# Use the diskutil apfs resizeContainer to | |
# assign all available free space on the | |
# drive to the APFS boot volume. | |
/usr/sbin/diskutil apfs resizeContainer /dev/"$apfs_container_id" 0 | |
else | |
echo "Filesystem detected: $boot_filesystem_check" | |
echo "Unknown filesystem on boot drive." | |
echo "Exiting with error." | |
ERROR=1 | |
fi | |
exit $ERROR |
when I do this command
diskutil apfs resizeContainer disk0 0
I get this error
Error: -69771: The target disk is too small for this operation
Hello, i got in High Sierra Error: -69743: The new size must be different than the existing size
diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *240.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 119.8 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme – +119.8 GB disk1
Physical Store disk0s2
1: APFS Volume Mac 116.1 GB disk1s1
2: APFS Volume Preboot 19.4 MB disk1s2
3: APFS Volume Recovery 509.8 MB disk1s3
4: APFS Volume VM 2.7 GB disk1s4
Any ideas?
Hi Steve, did you manage this? I am still struggling with this since a few hours
Reblogged this on [+] Blog del Chote [+].
Dedicated vm os x image on a 250GB 550ms SSD
HFS and VMware – while booting:
command+s
At single mode prompt: fsck -fy
Repeat until there’s no more errors
At prompt: reboot
From terminal as root execute:
/usr/sbin/diskutil resizeVolume / R
Done
HFS and Parallels – Do before booting
In VMConfiguration-> Hardware -> Boot Order > Advance enter the following
devices.mac.boot_args=”-s”
Then boot image
At single mode prompt: fsck -fy
Repeat until there’s no more errors
At prompt: shutdown -h now
In VMConfiguration-> Hardware -> Boot Order > Advance remove the entry
devices.mac.boot_args=”-s”
Boot into vm image
From terminal as root execute:
/usr/sbin/diskutil resizeVolume / R
Done
Tried to do the above, but it failed.
Turned out I had an Apple_KernelCoreDump partition in the way:
diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *64.4 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 49.6 GB disk0s2
3: Apple_KernelCoreDump 655.4 MB disk0s3
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme – +49.6 GB disk1
Physical Store disk0s2
1: APFS Volume Macintosh HD 43.0 GB disk1s1
2: APFS Volume Preboot 44.2 MB disk1s2
3: APFS Volume Recovery 516.7 MB disk1s3
4: APFS Volume VM 1.1 GB disk1s4
Was able to:
sudo diskutil erasevolume “Free Space” %noformat% /dev/disk0s3
sudo diskutil apfs resizeContainer disk0s2 0
to get there. I assume disk1 would have worked, too.
Thanks it greatly worked !!
Thanks, I was almost desparate because it did not use the free space. I could only shrink the container. Then I did a diskutil repairdisk disk0 and then it worked flawless
Wonderful!
It would be great to see the same example but with an existing BootCamp partition in place within the APFS container to use unallocated space outside of the APFS container.
Attempts to use these command lines with a High Sierra partition and its associated BootCamp volume to increase the APFS container to use unallocated space were unsuccessful.
Goal was simply to swap out a 1TB Samsung 850 Pro to a 2TB Samsung 850 Pro. Backups were made and experimentation began.
Using a physical drive cloner (non-software), the larger 2TB hard drive was cloned from the original 1TB driive successfully. Emplacement of the newly cloned 2TB hard drive boots up and works flawlessly both for High Sierra and its associated BootCamp volume. Attempts to expand the APFS container to utilize the remaining unallocated space were met with failure.
(“Error: -69771: The target disk is too small for this operation”)
This, of course, is false, as when in BootCamp, using MiniTool Partition Wizard 12 (free version), an exFAT partition was easily created making sure to use an allocation size 1024kb or less (in this case, 64kb to match default apple exFAT allocation sizing). Additional space is recognized in BootCamp, but not in High Sierra (it does NOT even show there is a partition/drive/container/volume at all–even with repair commands, etc.).
Every article I have come across to date, forum or otherwise, addresses shrinking/decreasing, but not expanding, save for a few like this one (kudos to rtrouton). However, none have addressed the method with an associated BootCamp volume within the APFS container (in this case, 1TB) and unallocated space outside of the APFS container (the other 1TB from the unallocated space of the larger replacement cloned 2TB hard drive). Both CarbonCopyCloner and WinClone do not preserve BootCamp boot capability; and therefore, are not solutions (maybe rtrouton can show some more of that intellectual prowess :))
Thank you!
The diskutil repairdisk along with the original process worked when the GUI would just play dumb.
I had to execute
diskutil repairdisk disk0
followed by
diskutil apfs resizeContainer disk1 0
Otherwise “diskutil list” would still show an unchanged size of disk0s2. And calling “diskutil apfs resizeContainer …” again would fail in “Error: -69743: The new size must be different than the existing size”.
Hi nharrer,
Just followed your steps. Thank You! It worked.
Awesome exactly what I needed. I was a bit scared when it asked that it might erase EFI, but all good +1
This was the only way I could get it to work… but then my system was unable to boot after I shut it down 😦
you saved my day. thanks
Thanks for this tip.
hi,
everything you have mentioned is me for me , but I am getting this error
Error: -69743: The new size must be different than the existing size
pls help me..!
thank you.
This appears to work great on windows virtualbox 6.1 macos monterey client, …but vm fails to boot afterwards getting kernel panics. Any ideas?
diskutil repairdisk disk0
diskutil apfs resizeContainer disk1 0