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...

My concern was that a "new config" would force drives to be reformatted when I added them back into the array. However, it's not required to reformat a drive to put it into the array. I know that now.. So I'm in the process of rebuilding parity for the array which consists of the untouched data drives. Once this is done, I have the drive that failed due to wiring issues passing both the Smart checks and a full preclear waiting in the wings. I'll add this as a blank drive into the array, copy the data from my backup back into place and be back where this all started. Thanks!

Unfortunately, I already formatted it. Yes, I admit, it was a stupid thing to do, and I usually know better. This was a multiple drive failure due to a cabling issue I induced when inserting a new drive. I was able to copy the data off the drive BEFORE I erased it, so I've not lost anything yet, except a bunch of time. Right now, I'm waiting for the parity to finish rebuilding. I've got the data drive precleared waiting in the wings and I'll add it back into the array. Once it's formatted and everything is in sync, I'll copy the data from the backup to the old drive. Then I'll be back where I started.

Ok, Right from the start, I'll admit that I'm stupid, but it was late, I was tired and I didn't understand what was happening. This all started because I had a new larger drive to install, and being the largest I was going to put it in the parity slot. Nice plan. To make a long story short, I had two drives fail (Parity and disk 1) due to both cabling issues and a stupid mistake. I managed to backup the data on the bad drive to another drive not in the array. I currently have two drives precleared and ready to go back into the array but I'd like to preserve the data on the three drives remaining. How can I do this? I'm guessing it's through tools -> New Config but the warning on that page has me concerned. Can you add drives with data back to an array and not lose the data when you do if I start a new config? If so, how? Thanks for helping me out.

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.