kc4uai

That does seem like a long time. It took me, in the USA, in the morning, on a 150 Gbps internet connection about an hour to download Big Sur using method 2. (I never got method 1 to work) One thing I figured out the hard way though was that once you start the container, DON'T STOP it until you have completed this download. IF you do, you will have to go clean out both appdata and any partial ISOs manually from the file system.

I figured it out myself.. But just in case somebody else has this issue... The problem was the file permissions of the two replacement (discussed in this bug report: https://github.com/SpaceinvaderOne/Macinabox/pull/49 ) files after they were copied into the Macinabox Docker container. When you pull them using wget, the permissions get set to your user's default and then when you copy them into the Docker container they have the wrong permissions (most notable the "unraid.sh"). The solution is easy. Just run "chmod 755" on both files before you copy them up to the container. (For example: "chmod 755 unraid.sh") I also had to switch to "method 2" for fetching the OS media (edit this in the Docker config when you install it). After that, things worked as expected. Thanks!

I followed the instructions for that fix and it's still in the crash boot loop when trying that first boot. Am I correct, that you install the MacInABox Docker (but don't let it start) then grab the two files and run the docker commands in question to update the files in the container... Then and only then you let the docker run? Even after a full erase of everything, app data, the VM disks and even the ISO and reinstalling per the amended instructions it's still failing to boot even the first time. Thanks for any suggestions...

I think I do. There are some security issues with this idea. Running commands as an administrator (i.e. root) is dangerous, do you allow it? Run commands as a lessor user? Also, from my perspective, it's not totally clear how something like this should work. File copies can take a long time to finish, do you block the web interface during this time? Allow for interrupting the operation while in progress? What about errors and recovery? Do you expect undo? Then there is the problem of increased support costs. When you add a complex feature like this, you add to your future support costs for user questions, debugging and things like that. Not to mention that it really kind of changes the complexion of what Unraid has traditionally been. However, that doesn't prevent *somebody* from doing this very thing as a plugin, or docker to support the wanted features. In that way, the system owner can decide what security risks they are willing to take, which container or plugin meets their needs. Given the available third party options, it seems to me that the Unraid solution is better off without this feature. At least that's how I see this.