JonathanM

Depends on which container you are using. Click on the icon in the GUI and select support, that will link to the support area for your container where you can find out how your specific container handles updates.

Yep, remove the folders that the container created in the icecast folder and replace them with the files.

If you don't receive an automated response in a few minutes it didn't go through properly, try again.

If the data layout is unchanged, then parity would be valid. However... I'm not sure how to figure that out without just doing what you said. I don't see any issue with your plan, I would definitely check the box stating parity is valid, that way there will be a parity check triggered instead of a parity build. If there are zero errors and the disk mounts, then you will be good to go. If there are immediately a wallop of parity errors and the disk doesn't mount, cancel the check, stop the array, unassign the disk, and start the array and see if the emulated disk mounts. If it does, then a rebuild on all the drives, one at a time, would fix it.

If the containers don't have a built in permission fix setting, (some of binhex's do) then the easiest way is to delete the appdata and start over. That will lose all your settings and data however. Otherwise it's probably going to be a tedious process of manually setting the permissions to what is needed, the only way I can think of would be do a second install and see what the permissions were on a running install and emulate them. Each container will be different, so I recommend asking in the support thread for the specific containers you are working on to see if there may be a shortcut to fixing it.

Make sure the power going to the drive is clean. Splitters and any push in connectors can cause issues.

I hadn't thought of that, great point! Mounting with Unassigned Devices still requires the array to be started AFAIK, so whether it's UD or a pool is going to be the same in that regard, neither will allow logging to continue during shutdown.

I can't solve that part of the question, but I can offer a workaround. Since there is no limit on additional pools, why not just assign the flash drive to a single device pool, call it logs or something? It's not like it has to be an unassigned device for removal purposes, since if the server is running it needs to be attached, and when the server is shut down and you need to read the logs it won't matter that it's in a pool. The only issue I can think of is if you need to read it on a windows system for some reason, in which case just use BTRFS and install https://github.com/maharmstone/btrfs

First, I don't recommend using a database container for multiple apps. There is practically no benefit to doing so, and plenty of reasons not to. Set up a second identical container changing the name, appdata folder, and port. That way if you mess something up you only have to deal with one container being down instead of all the containers using that same database engine. Containers share application layers, so the only additional space used is for the data, which would be additional anyway. Second, you should look at the existing support area for the container you are trying to get running and see if your questions are already answered there, if not, post in that support thread. This general area is for OS issues, containers have their own area. Click on the icon in the GUI and select "support".

Probably should post your docker run command in the support thread for your specific container. There are a bunch of different sonarr containers. You can find the support thread for yours by clicking on the icon in the gui and selecting support.

binhex's vpn containers are locked down tight, all IP's that need to access the GUI must be whitelisted in the container template. See Q30 https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Probably a good idea to read the whole thing, there's a lot of good info about using his containers. p.s. Each container has it's own support thread, to keep all the information in one place. You are meant to post in the specific thread for container support, not start a new thread. For Unraid OS specific questions, you ARE meant to start your own thread in the general support area.

When you do that make sure the vdisk type is correct.

Diagnostics may show the issue. I suspect either one or more of the drives is having problems reading, and all the retries are slowing things to a crawl, or there is something accessing the array reading and writing while the rebuild is happening. Rebuilding a drive requires reading simultaneously from all the other drives, so any issues with data speed will impact things greatly, as will any reads or writes to the array. Do you have anything else accessing the array, like docker containers or VM's, or network clients?

How are these drives connected? Motherboard model, HBA model, etc.

@SpencerJ@Adam-MIs there anything you can suggest? Or just keep submitting tickets until they get the automated response? I know this is frustrating for everyone, but some communication would be nice, and since the forum is obviously still running perhaps that communication needs to be some acknowledgement from the company here. Telling people to contact support and getting feedback here from prospective customers that the support ticket system isn't working isn't productive. If there is no known issue with the support ticket system, that would be nice to know as well.

That means the ticket didn't go through.

Not at all. It's that USB can be flaky, random disconnects and reconnects, not passing drive information completely or accurately, other issues. Unassigned devices is just a convenient way to manage disks not assigned to the array or pools. It doesn't have anything to do with the attachment method of said drives, be it SATA, eSATA, SAS, or USB. Some USB chipsets can work ok, but it's hard to know ahead of time whether a specific combo is going to give issues.

Or fix the templates by removing blank entries.

No, definitely NOT suggesting you move from a disk to a share. That can lead to data loss if you don't know what you are doing. I'm saying move from disk to disk. Both of the tools I mentioned will not allow you to move from disk to share.

How did you measure that? It seems low to me. Don't forget to add the network equipment that will be running on the UPS as well.

Sure, as long as the surge protector with all the computers and stuff has continous power when you switch the UPS source power off. If you can cut the power to the UPS without unplugging it you don't need that surge protector in line with it. Most wall sockets in the US don't have switches so I specified a switchable surge protector to provide a way to turn off the power to the UPS without disturbing the earth connection. Not quite sure I understand this. Computers and stuff should have a constant source of power throughout the test, the only thing switched is the UPS input. The reason I specified a surge protector for the critical equipment is to have them all on the same circuit with some level of protection from power issues. Do you have a way to figure out the power draw of the servers and network equipment? The test accuracy depends on the dummy load being close to the actual load.

Unbalanced plugin, or Dynamix File Manager plugin

Temporarily obtain 2 surge protecter power strips with switches. We need to turn off the power without breaking the ground circuit, so no yanking plugs out of the socket. Obviously starting with both servers safely shut down, along with everything else you plan to plug into the UPS. Plug all the power cords that will go to the UPS into surge protector 1. Plug the UPS input into surge protector 2 Make a (hopefully measured) educated guess on max power draw of everything plugged into surge protector 1. Bonus points if you have an accurate wattmeter to feed surge protector 1. Leave the USB connection from the UPS going to Unraid 1. This is why you need surge protectors instead of yanking the plug. Very bad things can happen if the UPS ground isn't tied back to the PC when it loses power. Fire up the UPS with nothing but the USB lead and power input connected. Boot up all the equipment on surge protector 1. Start a non-correcting parity check on both Unraid servers, and have everything started and loaded like it would in a worst case unattended power outage. Read the power draw if you have meter of some sort. Connect a similar draw non critical load to the output of the UPS. Good candidates are halogen work lights, incandescent lights if you have any around any more, space heaters on low, use your imagination to find enough load. Now you are ready to start the actual testing portion. This should be done with observation only, resist the urge to manually intervene. You should have a way to watch the dashboard of both Unraids. Turn off the surge protector feeding the UPS to start the "power failure". Observe the loads connected to the UPS, look for flickering lights or fan speed variations on the heater, whatever you have connected. Remember to turn off any tech not connected to UPS, to accurately simulate a power outage. Optionally for a more thorough test disconnect your outbound internet if you can do so safely, unless you are using cellular WAN, as a real power outage may drop the WAN outside of your control. Watch to see if you get notifications on the Unraid dashboards of a power failure. If everything is working to plan, Unraid 2 should start the shutdown process cleanly after 5 minutes. When it shuts down, you can adjust the load on the UPS to match, maybe turn off one of the lights connected. After the 10 minutes has elapsed, hopefully Unraid 1 starts a clean shutdown. When it's done, you can adjust the load on the UPS if you want. At this point if the UPS is still running the dummy loads, you can call it a success, depending on what you observed. Other considerations. After draining the batteries on a UPS, make sure you account for recharge time before depending on it for more backup, since a typical recharge rate is 10 to 20 times slower. If the UPS was running on battery for 15 minutes, allow at least 3 hours recharge time. SLA UPS batteries, the most common type, get touchy about being drained more than 50%. Their capacity and lifetime is reduced the deeper the discharge, so try to stay in the top of the curve. If you are discharging too deeply, reduce the time on battery parameter. Personally my secondary loads like client pc's, VM's, etc are all set to shut down after a minute or two of power outage. Keep in mind you can install apcupsd clients on any VM's hosted on Unraid to get them cleanly shut down prior to the main timeouts and reduce the shutdown time. If during the test the batteries are drained before the timed shutdown is done, you need to upsize the UPS, or restructure to multiple UPS since you are aiming for less than 50% drain, and you can't shorten the delay meaningfully. If the communication path between devices is broken or interrupted, the shutdown signal will be lost. Make sure all network infrastructure can outlast the full shutdown period. I recommend NOT trying to have things automatically recover after a power loss event. Much better to manage the recovery hands on, watching and controlling, especially checking UPS battery condition to ensure enough capacity to handle another shutdown if power goes out again during the boot up process.