Yes, it seems to be a bug. I got the same behavior in version 3.1.0. Upon investigation, the drive I was trying to use for the new location was my TimeMachine disk, which has plenty of space on it. However, the user running Docker did not have permissions to read or write to that disk. Normally, only the system itself is allowed to write to the TimeMachine backup disk, so you don’t mess up your backup. I got info on the disk for the new location (select disk, command-I), and at the bottom in the “Sharing & Permissions” section, I clicked the + below it to add permissions for a new user, chose the user that runs Docker, and then changed the “Privilege” column for this new user to “Read & Write”. After this, Docker was able to actually create the directory on the TimeMachine disk. I consider this a bug because Docker should have told me that it failed, and that the reason for failure was that the new target disk did not have read/write access. It pretended like everything was fine, and that is a bug. Also, for people who may not be able to find this feature, it is in Preferences, Resources, ADVANCED. But for me, the location option was scrolled off the page, and because I use a trackpad, there were no scrollbars to indicate that there was more below. Using two fingers to scroll down showed the “Disk image location” option.
I’m wondering the same thing too. I’ve installed Docker Desktop for Mac, then I used the GUI to move the disk image location. Docker restarted and now I can see the “Docker.raw” file in the new location.
Is this correct? I’m trying to validate that the containers, volumes, and images all live under the docker.raw file. I want to make sure because I want to store all these items on faster storage.
I found the command to browse the VM created by docker: `screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty" however, when I run this I get “no such file or directory” - I assume because I’ve moved the image?
So really two questions here:
#1 is docker.raw all my containers, images, and volumes?
#2 how can i browse the linux VM using the above command?
I’m running the most up to date version of Docker on Macbook Pro M1 as of Dec 2021. This thread is years in the making. Is the sym link option still the best way to do this? I see a few later references people configuring this in the options, but I cannot find it.
Please advise, thanks!
This thing just bit me hard: upon the first run, Docker ate all free space on my encrypted drive and crashed itself nearly dragging down the whole system with it, as the default disk image size is set to 64Gb! Insanity. FYI, if APFS runs out of space, it can lead to massive data corruption, so this practice is inherently dangerous. How hard can it be to check upon free disk pace before droping such a huge file in there???
Either way, as someone above correctly mentioned, you can change image location in Resources > Advanced settings, and SCROLL DOWN, as this crucial setting is hidden below the fold.
the use case is:
My MacStudio has an internal SSD with the OS, and it also has an external RAID enclosure with several volumes (macOS under /Volumes). One of the volumes is an SSD, with 2GByte (2000MB/sec) read and write. It does not make sense, to save virtual machines on the boot disk (Parallels, Fusion … I have all on the external disk). The RAID is connected to one of the four TB ports (40Gb/s) the Studio has.
For a macOS Docker app, it should be possible to configure all VM related storage (i.e. not on the internal disk). While this may be a good setting for a laptop it is not a good setting for a Desktop (MacMini, MacStudio, MacPro, iMac) which has external disks attached.
The reason to use external disks is for load leveling (i.e. reduce trashing); and with SSD in particular: my external SSD has a specified lifespan of 5 years (assuming the entire disk is written/day); as specified by the manufacturer (server part). For the built-in SDD of the Macs lifespan is no different.