+1, voting for this as well - I quickly run out of disk space on my MacBook Air when trying to bring up containers.
+1 what they said. I have been experimenting with Kitematic to achieve this but with minimal success thus far
What about simply moving
~/Library/Containers/com.docker.docker to another volume and symlinking it back to
Well what about adopting the ENV variables the same way docker toolbox would. ? I’m surprised that something like this is such a debate. Disk space is really an important factor and it think its obvious that one would want to be able to preserve their device as much as possible. I think being able to configure how a software uses up your disk space should be something taken into consideration when devising these tooling apparatuses.
Yes please, enable a way to changing this, it’s killing my main disk as well. What mbklein proposed is a nice workaround “patch” but not a real fix to a critical feature.
Like other my main disc on my mac is full I wish I could move the images on another disc.
Just to confirm, the proposed symlinking solution worked for me.
> sw_vers ProductName: Mac OS X ProductVersion: 10.12.1 BuildVersion: 16B2555 > docker --version Docker version 1.12.3, build 6b644ec > rsync --version rsync version 3.1.2 protocol version 31 ...
cp -R com.docker.docker /Volumes/..., I had to do
rsync -a com.docker.docker /Volumes/...
some files are “socket” files and they refused to be copied via cp.
Yep, just to confirm a second time - that’s a working solution…
Actually it’s fine to just move the Docker Image to the location of your choice and symlinking that. Then you don’t run into the socket errors mentioned by drwin:
mv /Users/<username>/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 /<path-of-your-choice>/ ln -s /<path-of-your-choice>/Docker.qcow2 /Users/<username>/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
When using Docker for Mac, there is a preference for the the storage location in the advanced tab. You change the location and confirm with
Apply & Restart. Docker for Mac will move the storage archive and take care of the rest. This can obviously take some time depending on storage size and disk speed… be patient.
this is working solution. thank you!
I used the move Disk image location option in Docker Preferences (Version 18.03.1-ce-mac65 (24312)) and after a restart Docker doesn’t find the images. Running docker images in Terminal doesn’t return anything other than the header fields. I moved the images to an external Transcend JetDrive to reduce the container build up on the Mac drive. Is there something else I need to do to point Docker to the images? I was thinking of uninstalling Docker then reinstalling and before creating anything change the image location but this is a bit more drastic than what I was hoping to do. Thanks!
Thanks, I was able to set this up using your suggestion. I took some time to document the process for anyone that comes in search of answers. How to store docker images and containers on an external drive.
For me works in macOS (Sierra and Catalina) with:
ln -s /Volumes/Transcend/com.docker.docker/data/Docker.qcow2 /Users/joseluisbz/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.qcow2
Check the route is different.
I’m on desktop version 18.104.22.168. I changed the location in the preferences and clicked apply&restart. It successfully restarted. But when i check there is not file under the new folder i created as the new location. Also if i close the desktop interface and then opened it again, the path went back to the old one. I have tried multiple times but no luck. Is it a bug?
Thanks for your post, this helped me too.
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.