Docker Desktop supports moving the VM Image that it uses onto another drive if needed. On my Mac Mini (2018) I have moved it to an external SSD in order to enlarge it more than the internal storage would have allowed.
The external SSD was named "Extra Space", which (ironically) became a problem when I also tried to use the SSD for other non-Docker development and discovered that some of the Ruby Gems I am using have problems with spaces in path names.
I decided that I would have to rename the drive to "ExtraSpace" (without the "extra" space), but then Docker was not able to find its VM Image. I was unable to use the built-in location chooser ("Preferences" -> "Resources" -> "Advanced" -> "Disk Image Location") because that tool assumes that it is moving the image from one location to another but in my case the image is not being moved, only the path to the existing image is changing.
I looked through the Docker configuration in ~/Library/Containers/com.docker.desktop/ and found the path to the image in Library/Containers/com.docker.docker/Data/vms/0/hyperkit.json. I tried changing it there, but Docker Desktop would not start.
In the error logs, I found lots of messages like this:
time="2021-10-31T15:06:43-04:00" level=error msg="(5487d9bc) 4ecbf40e-BackendAPI S->C f68f0c84-DriverCMD GET /vm/disk (925.402µs): mkdir /Volumes/Extra Space: permission denied"
common/cmd/com.docker.backend/internal/handlers.(*VMInitHandler).VMDiskInfo(0x58c13b8, {0x58b94a0, 0xc0001d82a0})
common/cmd/com.docker.backend/internal/handlers/vminit.go:39 +0x42
Why does Docker Desktop not follow the VM configuration file to find the location of the image? Is there somewhere else I have to change it?
After a lot more searching, I found the following additional files that need to be updated with the new path:
~/Library/Preferences/com.electron.docker-frontend.plist
~/Library/Preferences/com.electron.dockerdesktop.plist
~/Library/Group Containers/group.com.docker/settings.json
Once I had updated all of these files with the new path, Docker Desktop was able to start up correctly.
Related
I am running SRS from a Docker container. On Manjaro I can issue a docker command in terminal, and stream video from OBS to the SRS instance I just launched. I can then view live video in a web page, from that server.
BUT!
The configuration is a bit opaque. The config files refer to a directory ("./objs") that is likely defined in a config file, but I can't find it.
AND!
I'm still a bit confused about how Docker works- isn't there a straightforward way to edit an image or container?
I can see all the config files in /etc/srs (like srs.conf, rtmp.conf and so on). The config files refer to the directory ./objs for the location of (for instance) the nginx root, index.html. But I cannot find that directory.
I also have installed SRS from official repos, on the same machine. I launched srs from /usr/bin/srs (not from the Docker image), but it immediately quits. So I gave up for now. Running it from Docker seems to work pretty well.
When start SRS by docker, it actually the same to start in shell:
cd /usr/local/srs && ./objs/srs -c conf/srs.conf
You can also use docker inspect ossrs/srs:5 to get the information:
"Cmd": ["./objs/srs", "-c", "conf/srs.conf"],
"WorkingDir": "/usr/local/srs",
The current work directory is /usr/local/srs, so ./objs is /usr/local/srs/objs, and I will describe more about why relative directories.
The configuration file is conf/srs.conf, which is actually /usr/local/srs/conf/srs.conf, and there are lots of configuration examples in ./conf.
The examples in ossrs.io is in the same format, uses a configuration and depends on the work directory.
SRS uses relative directory ./objs or ./conf because there are some features depend on it. You can see full.conf for all the configurations that supported.
We use relative directory because you can easily change to other directory, or start more than one SRS server. Of course, you could change the relative directory to abolute directory, please search ./objs in full.conf, for example:
pid ./objs/srs.pid;
ff_log_dir ./objs;
srs_log_file ./objs/srs.log;
http_server {
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
hls {
hls_path ./objs/nginx/html;
}
Please note that you can use docker volume to mount directory of host for container.
How can I change the default location for storing Docker images in Windows? I currently have Docker installed on my C: drive, and the images are stored in the following location:
C:\Users\xxxxx\AppData\Local\Docker\wsl\data.
I want to change the default location to my D: drive. I am using WSL2 as the backend for Docker, and I have read that I can use the .wslconfig file to configure Docker. However, I am not sure how to set up the .wslconfig file to change the default image location. My WSL2 installation is located on my D: drive, which I installed from the Microsoft Store.
I'm using Docker version 20.10.21 and these are wsl specs
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1335
I'm using Ubuntu distro in WSL, and Docker Desktop v.4.15.0
I tried making some changes in .wslconfig but there was no option for storage or something.
Caveats/Preface:
I've tried this and it works, but I cannot guarantee that long-term it will continue to work. There's the potential that something will break when Docker Desktop upgrades in the future.
In general I don't recommend registry hacks, but I'm not aware of another way to do this. Other than the previous caveat, this seems fairly safe.
No, there's no .wslconfig option for changing the location of a distribution.
With that in mind, here's what I did to move docker-desktop-data to the D: drive:
Create the directory. I'll use D:\wsl\docker-desktop-data as an example.
Stop Docker Desktop by right-clicking on the status bar icon and Quit Docker Desktop.
From PowerShell:
wsl --shutdown
Confirm the location (BasePath) and registry key (PSChildName) of the docker-desktop-data via:
Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\ |
ForEach-Object {
(Get-ItemProperty $_.PSPATH)
} | Where-Object {
$_.DistributionName -eq "docker-desktop-data"
}
Move ext4.vhdx from the BasePath directory identified above to the D:\wsl\docker-desktop-data directory.
In regedit, navigate to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss
Find the subkey matching the PSChildName from above.
Modify the BasePath to point to \\?\D:\wsl\docker-desktop-data
Restart Docker Desktop
Test that your existing images are still available by running one of them.
Steps to reproduce are very easy.
Create a Dockerfile.
My Dockerfile has many more lines, but I have trimmed them so we can focus in the source of the problem.
Said that, these two lines alone (without anything more) show the problem.
FROM microsoft/iis
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $VerbosePreference = 'Continue'; "]
Run docker build . and you get hcsshim::PrepareLayer - failed failed in Win32: Función incorrecta. (0x1).
Windows 10 Pro 1909 (but it happened too in 1903)
Docker version: 2.1.0.5
Engine: 19.03.5
Machine: 0.16.2
I have found the solution to the problem.
Reading all the https://github.com/docker/for-win/issues/3884 bug, some have found a simple solution: rename C:\windows\system32\driver\cbfsconnect2017.sys so it isn't loaded the next boot.
Disabling that driver enables me to do a docker build for the first time in windows containers in almost a year.
In my case Box Sync was the one using that driver.
EDIT: #GustavoTM have found that pCloud raises the same problem.
EDIT2: #VonC have noticed that some people in the issue in GitHub has solved it deleting this other file: C:\Windows\System32\drivers\cbfs6.sys. I haven't tried that, but i put it if it helps others.
The good thing is that I don't need to uninstall Box, but only rename that file.
This is still an issue (still open) with Win10.
Looks like uninstalling cloud storage providers with file system filters like Dropbox, Box, etc. as a workaround is an option for some users.
Deinstall cloud storage providers or virus scanners; if you identify which one is not working please share in https://github.com/docker/for-win/issues/3884
In my case was the problem similar but the file cbfs6.sys was placed somewhere in the rest of uninstalled application Jungle disk, somewhere in the folder c:\Program files\Jungle disk .... It's part of Callback File System signed by EldoS Corporation.
The folder could be rename only and not delete directly. So I could delete its immediately after the PC restart, before running the Docker. So it could be delete during the Docker service restart too.
I am using Oracle Virtual Box version 4.2.16 r86992. Everything was fine until yesterday shutdown.
Today, it shows inaccessible and throws this error:
Runtime error opening C:\Users\xxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\vBoxxxxXubuntu_Beta.vbox for reading: -102 (File not found.).
D:\tinderbox\win-4.2\src\VBox\Main\src-server\MachineImpl.cpp[725] (long __cdecl Machine::registeredInit(void)).
It's good to restore this to working, It would save lot of time and restore configuration settings and data. Thanking your support.
This normally happens if the host OS crashes or you pull the plug on it, leaving the .vbox file unsaved.
In the location:
C:\Users\xxxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\
you should find two files:
vBoxxxxXubuntu_Beta.vbox-prev
vBoxxxxXubuntu_Beta.vbox-tmp
Copy vBoxxxxXubuntu_Beta.vbox-prev to vBoxxxxXubuntu_Beta.vbox.
Select vBoxxxxXubuntu_Beta.vbox, in the VBox manager, right click, and then left click on refresh.
Observe that it now shows Powered Off.
Now you are good to go.
Based on my experience, I was on Windows 7 and running Ubuntu 14.04 as guest OS on Virtual Machine.
Go to your Virtualbox folder (in my case):
C:\Users\Dev12\VirtualBox VMs\Ubuntu
You'll see files with extensions: Ubuntu.vbox-tmp or Ubuntu.vbox-prev
Remove -tmp from file name Ubuntu.vbox-tmp so that it reads as Ubuntu.vbox
Exit from Virtual Machine and start it again.
You should now see error gone away.
The virtual box files with extension .vbox contain metadata the virtualbox hypervisor requires to resolve the guest virtual OS' configuration.
If the main .vbox file is corrupted (i.e. reporting that it is empty) then use the backup .vbox-prev file to recover the contents of the original file.
Do this by renaming the empty .vbox files a temporary name (e.g. rename originalVM.vbox to originalVM-empty.vbox).
Then make a copy of the backup file originalVM.vbox-prev, where the copy will have the same name as the original but with the word "copy" appended to it (i.e. originalVM.vbox-prev is renamed to originalVM (copy).vbox-prev).
It is important to retain the original backup .vbox-prev file it should not be altered or itself renamed.
Now go rename the copy of the newly created .vbox-prev file originalVM (copy).vbox-prev to the original name of the empty .vbox file and be mindful to also change it extension from .vbox-prev back to just .vbox.
That is rename originalVM (copy).vbox-prev back to originalVM.vbox. Now that this is done you may add the .vbox file (guest os) back into the VBOX hypervisor. This will recover the state and snapshot of the "inaccessible" guest VM. Now delete the original empty .vbox file.
I've faced the same issue using CentOs 6.8 on a VirtualBox 5.1 installed in Windows 7 and AjayKumarBasuthkar's solution worked perfectly for me:
I went to C:\Users\\VirtualBox VMs\CentOS6.8
Made a copy of the file CentOS6.8.vbox-prev and gave it the name of CentOS6.8.vbox
Went to the VirtualBox GUI, right-clicked the VM instance and hit refresh
The CentOS instance went from the State Inaccessible to Powered Off
VirtualBox 4.3 is released and could it be that you've updated or there was some issues while updating?
In any case if you are not able to bring up the Virtualbox, remember to backup the VirutalBox VMs folder and going for a fresh install should be the best way forward.
I faced the same problem and I resolved by doing following in Oracle Virtual box 4.3.28 with Ubuntu 14.04 LTS, when Virtual box VM was closed.
Removed ubuntu.vbox to another folder outside virtual box folder
removed -prev from file ubuntu.vbox-prev
start oracle virtualbox, it works excellent.
On a Windows 7 Host, I found that Daemon Tools service had a hold on the file.
The solution was to uninstall Daemon Tools, but I suspect if you stop the service and remove the file association, you would be sorted.
The other issue might be that if your Virtual Machine was on an external hard drive, it is possible that the drive letter has changed. If so, go to Computer Management, and select the hard drive and right click to change the drive letter and save (Note that this is for Windows).
This is going to sound stupid but try to reinstall VB. It may work.
I am adding one critical and important comment to the previous great answers. Make sure that the original .vbox file is corrupted and empty before you copy the content from the.vbox-prev file. If it is not the case and you find it with lines and readable content, don't replace the content of the .vbox.
Changes made to the VM directly before the VM got inaccessible might not be updated in the .vbox-prev backup file . The changes could not be synced with those changes before the OS upgrade or system changes that led to the inaccesable issue.
If you find your VM not accessible after an OS upgrade or system change, first check the.vbox file if it is still readable by a text editor and it has lines. Then you just need to delete the VM from the VirtualBox manager list(just remove the appliance from the list and don't remove files) . Then reopen the.vbox file and it should work perfectly.
If the original.vbox file is corrupted or empty when you open it with a text editor, then and only then, you can copy the content from the .vbox-prev and follow the instructions highlighted.
This was my experience, and I wanted to share it with you to avoid losing some last minute changes before the OS upgrade or crash.
What happens to the .box file after the following command is executed?
vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
I can't find the lucid32.box file on the file system after download has completed.
As mentioned in the docs, boxes are stored at:
Mac OS X and Linux: ~/.vagrant.d/boxes
Windows: C:/Users/USERNAME/.vagrant.d/boxes
On Mac/Linux System, the successfully downloaded boxes are located at:
~/.vagrant.d/boxes
and unsuccessful boxes are located at:
~/.vagrant.d/tmp
On Windows systems it is located under the Users folder:
C:\Users\%userprofile%\.vagrant.d\boxes
Hope this will help. Thanks
To change the Path, you can set a new Path to an Enviroment-Variable named:
VAGRANT_HOME
export VAGRANT_HOME=my/new/path/goes/here/
Thats maybe nice if you want to have those vagrant-Images on another HDD.
More Information here in the Documentations: http://docs.vagrantup.com/v2/other/environmental-variables.html
The actual .box file is deleted by Vagrant once the download and box installation is complete. As mentioned in other answers, whilst downloading, the .box file is stored as:
~/.vagrant.d/tmp/boxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
where the file name is 'box' followed by a 40 byte hexadecimal hash. A temporary file on my system for example, is:
~/.vagrant.d/tmp/boxc74a85fe4af3197a744851517c6af4d4959db77f
As far as I can tell, this file is never saved with a *.box extension, which explains why the searches above failed to locate it. There are two ways to retrieve the actual box file:
Download the .box file from vagrantcloud.com
Find the box you're interested in on the atlas. For example,
https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20150530.0.1
Replace the domain name with vagrantcloud.com. So https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20150530.0.1
becomes https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20150530.0.1/providers/virtualbox.box.
Add /providers/virtualbox.box to the end of that URL. So https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20150530.0.1 becomes https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20150530.0.1/providers/virtualbox.box
Save the .box file
Use the .box as you wish, for example, hosting it yourself and pointing config.vm.box_url to the URL. OR
Get the .box directly from Vagrant
This requires you to modify the ruby source to prevent Vagrant from deleting the box after successful download.
Locate the box_add.rb file in your Vagrant installation directory. On my system it's located at /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/box_add.rb
Find the box_add function. Within the box_add function, there is a block that reads:
ensure
# Make sure we delete the temporary file after we add it,
# unless we were interrupted, in which case we keep it around
# so we can resume the download later.
if !#download_interrupted
#logger.debug("Deleting temporary box: #{box_url}")
begin
box_url.delete if box_url
rescue Errno::ENOENT
# Not a big deal, the temp file may not actually exist
end
end
Comment this block out.
Add another box using vagrant add box <boxname>.
Wait for it to download.
You can watch it save in the ~/.vagrant.d/tmp/ directory as a boxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX file.
Rename the the file to something more useful. Eg, mv boxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX trusty64.box.
Why would you want this?
For me, this has been useful to retrieve the .box file so it can be hosted on local, fast infrastructure as opposed to downloading from HashiCorp's Atlas box catalog or another box provider.
This really should be part of the default Vagrant functionality as it has a very definitive use case.
#Luke Peterson: There's a simpler way to get .box file.
Just go to https://atlas.hashicorp.com/boxes/search, search for the box you'd like to download. Notice the URL of the box, e.g:
https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20150530.0.1
Then you can download this box using URL like this:
https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20150530.0.1/providers/virtualbox.box
I tried and successfully download all the boxes I need. Hope that help.
On Windows, the location can be found here. I didn't find any documentation on the internet for this, and this wasn't immediately obvious to me:
C:\Users\\{username}\\.vagrant.d\boxes
In addition to
Mac:
~/.vagrant.d/
Windows:
C:\Users\%userprofile%\.vagrant.d\boxes
You have to delete the files in VirtualBox/OtherVMprovider to make a clean start.
On Windows 10 with Vagrant 2.2.2, setting the environment variable VAGRANT_HOME will ensure that boxes are downloaded to a subfolder of the folder specified for VAGRANT_HOME.
In my case I set VAGRANT_HOME to e:\vagrant_home, and the boxes get stored under e:\vagrant_home\boxes.
This works for me.
That's where the boxes are stored. The virtual machines are being created in the folder configured in Virtual Box. To set the VirtualBox VM storage folder, go to: VirtualBox GUI --> File --> Preferences --> General --> Default Machine Folder.